ppc multlibs and BSP removal was Re: powerpc altivec support

[Sergei Organov]

Ralf Corsepius <ralf.corsepius at rtems.org> writes:
> 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".

Because it's the way powerpc-eabi target works ;)

> 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.

Except that -meabi -msdata=[eabi|default] is broken in gcc 3.x. If it's
fixed in 4.0 (and gcc guys claim it is), then it could be made a
multilib variant if RTEMS switches to gcc 4.0.

> 
> > > * 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.

Am I blind? I fail to see it.

> 
> >  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

Well,

find ~/rtems-cvs-trunc -type d \( -name RCS -o -name CVS -o -name SCCS \) -prune -o -type f \! -name \*\~ \! -name \*\,v \! -name s.\* -name "*.[chS]*" -print0 | xargs -0 -e grep -n  -e PPC_ABI_EABI  /dev/null
c/src/lib/libbsp/powerpc/support/new_exception_processing/cpu.c:129:#elif (PPC_ABI == PPC_ABI_EABI)
c/src/lib/libbsp/powerpc/support/old_exception_processing/cpu.c:232:#else /* PPC_ABI_SVR4 or PPC_ABI_EABI */
c/src/lib/libbsp/powerpc/support/old_exception_processing/cpu.c:292:#if (PPC_ABI == PPC_ABI_EABI)
c/src/lib/libbsp/powerpc/support/old_exception_processing/irq_stub.S:145:#if (PPC_ABI == PPC_ABI_SVR4 || PPC_ABI == PPC_ABI_EABI)
cpukit/score/cpu/powerpc/rtems/score/powerpc.h:347:#define PPC_ABI_EABI		3
cpukit/score/cpu/powerpc/rtems/score/powerpc.h:354:#define PPC_ABI PPC_ABI_EABI
cpukit/score/cpu/powerpc/rtems/score/powerpc.h:363:#elif (PPC_ABI == PPC_ABI_EABI)
make/custom/mpc8260ads.cfg:30:  -DPPC_ABI=PPC_ABI_EABI -DPPC_ASM=PPC_ASM_ELF

Where exactly do you see more suspicious spots?

-- 
Sergei.