ppc multlibs and BSP removal was Re: powerpc altivec support

[Sergei Organov]

Ralf Corsepius <ralf.corsepius at 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.

-- 
Sergei.