ppc multlibs and BSP removal was Re: powerpc altivec support

[Ralf Corsepius]

On Thu, 2005-02-10 at 20:02 +0300, Sergei Organov wrote:
> 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).
Probably, I am inclined to agree.

Unfortunately, I don't know why powerpc-rtems-gcc multilibs use 
"-nno-eabi". 

I'd guess it is a side-effect of the ABI confusion and might have been
added to make stack corruptions unlikely by (unnecessarily) adding
overhead onto the stack ;-)

I.e. if you (ppc) guys tell me, we should not use -mno-eabi for
multilibs, I'd be glad to change this.

> > * 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.
+ Setting stack boundaries to 16 in asm code.

>  So "corrupted" doesn't in fact apply.
OK, I stand corrected.

> 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.
There are more suspicious spots inside of the code.

Check
grep -R PPC_ABI_EABI \
cpukit/score/cpu/powerpc \
c/src/lib/libcpu/powerpc \
c/src/lib/libbsp/powerpc

and then have a look at all places shown.

I suspect several of them not supporting SYSV and using hard-coded
"8"'s, but I haven't investigated in depth, yet.

Ralf