[cfe-dev] A new builtin: __builtin_stack_pointer()

[PaX Team]

On 8 Nov 2013 at 17:37, Richard Smith wrote:

> I don't think you've answered my main question: what semantics do you want
> the returned pointer to have (and how can any correct code ever do anything
> with the pointer)? If you just want some approximation of the stack pointer
> to use as a key, __builtin_frame_address seems like it would work.

linux can process IRQs on a separate kernel stack (instead of the normal
per-process kernel stacks) in order the reduce the chances of kernel stack
overflows (they're very limited in size). now linux also wants to be able
to walk across these stacks when producing a diagnostic backtrace (that may
very well happen while processing an IRQ on its own stack). different archs
solve this problem of finding one stack from another in different ways.

specifically the i386 kernel (arch/x86/kernel/irq_32.c) saves the 'current
stack pointer' value somewhere on the IRQ stack (before switching the esp
register, which is done in asm) and the backtrace code (that loop in dump_trace
in arch/x86/kernel/dumpstack_32.c) 'knows' where to find it and continues
the trace from this saved stack pointer value. all this logic probably breaks
the standard in a dozen ways so strictly speaking it's nowhere near compliant
but 'it works' (with gcc anyway ;). (as a sidenote, there's more stack walking
code in linux that assumes certain compiler behaviour but let's fix one problem
at a time)

now with that background let me try to answer your questions:

- __builtin_frame_address is indeed good enough for this purpose (and i can't
  find more use of the stack register in C, but maybe Behan knows of more where
  an exact value is important)

- the resulting value is expected to be a valid address (at the time it's taken)
  as the kernel *will* dereference it later but there're no other requirements.

> Do you *also* need a guarantee that the stack pointer will not change
> between the call to __builtin_stack_address and the end of the function
> (except in callees)? 

no, it just has to be an address that belongs to the current stack frame at the
time. basically it'll define the start address from which the kernel will look
for certain things (such as code addresses in the hope that saved return addresses
will be found this way) on the stack.

> Can we reorder a call to alloca() past __builtin_stack_address?
> Can we reorder the initialization of a VLA past a call to
> __builtin_stack_address? Can the backend choose to perform a stack
> adjustment afterwards?

yes for all.

cheers,
  PaX Team