4 ms·

You know what, I'm not actually sure. All I know is that it screws up your stack frames. I think I had to provide -mno-redzone on GCC command line. It's someth

by exDM69 9y ago

You know what, I'm not actually sure. All I know is that it screws up your stack frames. I think I had to provide -mno-redzone on GCC command line. It's something in the ABI (I was on x86_64, the ABI is rather complex) related to padding the stack frames when calling functions. I don't remember if this applied to all functions or was it something special needed for interrupt handlers.

gpderetta 9y ago
the unix x86_64 userspace abi guarantees that the 128 bytes (known as the red zone) above the stack pointer are guaranteed not to be clobbered by signal handlers. This an optimization that avoid the need for leaf functions to manipulate the stack pointer to allocate their stack frame. The linux kernel does not follow this part of the ABI, so the compiler needs to be told that there is no red zone or functions will randomly see their stack frame clobbered by interrupt handlers.
- DSMan195276 9y ago
  > The linux kernel does not follow this part of the ABI, so the compiler needs to be told that there is no red zone or functions will randomly see their stack frame clobbered by interrupt handlers. You're absolute right, but I would add a qualifier that it is impossible for a kernel to use the redzone optimization. Certain architectures (Like x86) will push data onto the stack when an interrupt happens and there is no way to tell them to put that data after the first 128 bytes on the stack.
  - convolvatron 9y ago
    you could use some register other than %esp for your stack :)
- throwaway613834 9y ago
  Doesn't red-zoning break the fundamental contract of a stack pointer -- i.e., that it marks the end of the stack (and hence the location of the next item to be pushed)? This feature sounds like a bug to me...
  - DSMan195276 9y ago
    In some ways yes, but it is only applied to functions where they call no other functions and thus "nobody" will ever know they never moved the stack pointer anyway. In those situations moving the stack pointer is just pointless extra work because it is a value that will never be used and then just restored to its original value. I say "nobody" because in particular signal handlers (Which are basically just userland interrupts) can interrupt any part of userland code. However since they are generated entirely by the kernel it is easy enough for the kernel to obey the redzone and place the signal handler 128 bytes above the stack pointer, so in practice this isn't that big of a deal.

by exDM69 9y ago

gpderetta 9y ago

the unix x86_64 userspace abi guarantees that the 128 bytes (known as the red zone) above the stack pointer are guaranteed not to be clobbered by signal handlers. This an optimization that avoid the need for leaf functions to manipulate the stack pointer to allocate their stack frame. The linux kernel does not follow this part of the ABI, so the compiler needs to be told that there is no red zone or functions will randomly see their stack frame clobbered by interrupt handlers.

DSMan195276 9y ago
> The linux kernel does not follow this part of the ABI, so the compiler needs to be told that there is no red zone or functions will randomly see their stack frame clobbered by interrupt handlers. You're absolute right, but I would add a qualifier that it is impossible for a kernel to use the redzone optimization. Certain architectures (Like x86) will push data onto the stack when an interrupt happens and there is no way to tell them to put that data after the first 128 bytes on the stack.
- convolvatron 9y ago
  you could use some register other than %esp for your stack :)
throwaway613834 9y ago
Doesn't red-zoning break the fundamental contract of a stack pointer -- i.e., that it marks the end of the stack (and hence the location of the next item to be pushed)? This feature sounds like a bug to me...
- DSMan195276 9y ago
  In some ways yes, but it is only applied to functions where they call no other functions and thus "nobody" will ever know they never moved the stack pointer anyway. In those situations moving the stack pointer is just pointless extra work because it is a value that will never be used and then just restored to its original value. I say "nobody" because in particular signal handlers (Which are basically just userland interrupts) can interrupt any part of userland code. However since they are generated entirely by the kernel it is easy enough for the kernel to obey the redzone and place the signal handler 128 bytes above the stack pointer, so in practice this isn't that big of a deal.