newlib on x86-64

["Neal H. Walfield" <neal at walfield dot org>]

I'm using the string routines from newlib in my kernel, which runs on
x86-64.  The x86-64 ABI includes the convention that the system must
consider the end of the stack to be designated by RSP + 128, not RSP.
From the x86-64 ABI documentation:

    The 128-byte area beyond the location pointed to by %rsp is
    considered to be reserved and shall not be modified by signal or
    interrupt handlers. Therefore, functions may use this area for
    temporary data that is not needed across function calls. In
    particular, leaf functions may use this area for their entire
    stack frame, rather than adjusting the stack pointer in the
    prologue and epilogue. This area is known as the red zone.

This convention works fine in user-land, however, it is a nuisance in
the kernel as the hardware is not in on the joke.  For instance, when
an interrupt occurs while in CPL0, the hardware pushes the CS:RIP,
SS:RSP and RFLAGS onto the stack, which may overwrite data saved in
the red zone.

To prevent this from being a problem, kernels are compiled with
-mno-red-zone.  I have done this when compiling my kernel and newlib.
Newlib, however, still uses it.  In particular, at least one assembly
file makes use of the red zone, newlib/libc/machine/x86_64/memcpy.S.

Is there interest in making newlib work with -mno-red-zone?  If so,
what is the preferred approach?  I'd suggest never using the red zone.
First, it controls the number of configurations.  Second, I doubt that
it will hurt performance relative to the current code.  Indeed, I
suspect that memcpy may be faster: pushing the registers will increase
instruction density: `movq rax, -8 (rsp)' is encoded in 5 bytes; `push
rax' requires just 1.  (I have not benchmarked this, however.)

Thanks,
Neal