Ralf Corsepius <ralf.corsepius@rtems.org> writes:
[...]
Well, as I understand it from digging in GCC's and RTEMS sources,
powerpc-rtems-gcc defaults to "sysv-eabi" (whatever this is).
All I can say is:
* we are using -mcall-sysv.
AFAIU, this means we are using SYSV calling conventions.
* The default stack boundary (This is the term GCC uses) is 8.
* -mno-eabi switches the stack boundary to 16.
* Explicitly passing -meabi doesn't seem to have any effect on the stack
boundary. Therefore, I conclude the implicit default is -meabi.
* ATM, the multilibs are being built *explicitly* using -mno-eabi,
i.e. newlib and GCC's libs are being built with a stack boundary of 16.
According to a comment in rs6000.c, this implies they are EABI and SYSV
compatible.
Except that for RTEMS building all the libraries with -meabi does
make sense as it decreases resulting executable size (and slightly
increases speed).
* There doesn't seem to be a preprocessor define denoting if using EABI
or SYSV.
So - what are we using? I don't know.
AFAIU, we are using SYSV for newlib/GCC (-mno-eabi -mcall-sysv) and a
corrupted multilib'ed cpukit (-mno-eabi -mcall-sysv -DPPC_ABI_EABI).
Except that PPC_ABI_EABI seems to have exactly the same effect on the
code as PPC_ABI_SYSV except that in the former case thread context's r2
is initialized with current r2 that can't break SYSV. So "corrupted"
doesn't in fact apply.
Strange thing is that CPU_MINIMUM_STACK_FRAME_SIZE is defined to 8 no
matter if SYSV or EABI is defined. And that's the case for both old and
new exception processing. Should be 16 for SYSV, I think. I myself
always use EABI (-meabi -msdata=eabi), so this bug doesn't affect my
code, -- don't know about those who use SYSV.