https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
Bug ID: 117312
Summary: RFE: x86 (and perhaps others): inline assembly:
"red-zone" clobber
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
When compiling with red zone, an inline assembly routine using push, call, or
other instructions which use the stack, will clobber the red zone.
An example of when this is unavoidable are constructs like pushf/pop to get the
current value of the flags register.
This is definitely used incorrectly in a fair bit of code in existence. It
doesn't *currently* affect kernel code (for any operating system) since kernel
code has to be compiled with -mno-red-zone, but with FRED enabled it is
possible to compile the kernel with red zone enabled, at which point this would
affect the kernel as well.
There doesn't seem to be any direct way to make gcc aware that the redzone is
clobbered. Even something like:
register void *current_stack_pointer asm("%rsp");
struct redzone {
unsigned char rz[128];
};
#define REDZONE (((struct redzone *)(current_stack_pointer))[-1])
asm(.... : "+r" (current_stack_pointer), "=m" (REDZONE) ... : "memory");
... fails to prevent redzone use, as does forcing a frame pointer using
__builtin_frame_address(0) as described in bug 117311.
The most logical way to address this would seem to be to allow "red-zone" to be
specified in the assembly clobber list, just like "memory" or "cc". The
simplest "heavy hammer" implementation would be to disable red zone support for
the surrounding function.
