RTEMS powerpc eabi? PR195

Wed May 22 11:51:13 UTC 2002

Hello again,

ok Ralf, I got your problem and I have tried to get further 
information. 

- gcc2.95.2 prints similar output with option "-print-multi-
lib", so there is no change in gcc-3.0.4

- I have built a gcc-3.0.4 today for target "powerpc-unknown-
eabi", it also prints "no-eabi" in the multiplib output !!!

- I had a look at the eabi specification. It is really closely 
related to the SVR4 ABI, so linking SVR4 libraries to EABI 
applications should work. There are diffrerent requirements 
concerning stack alignment and some other areas, but up to now 
I _guess_, that there is not a real technical problem.

Does anybody else on the mailing list have further/different 
info?

I will once again check the EABI document tomorrow, I will 
keep you informed.

Bye,
	Thomas.

> Am Mit, 2002-05-15 um 23.31 schrieb Thomas Doerfler:
> > Hello Ralf,
> > 
> > tonight I have checked about the big question "eabi or not abi"?
> > 
> > first I have checked the compiler (gcc 2.95.2), it conforms to 
> > the eabi convention by default. The I have grepped through the 
> > RTEMS source tree including the make files. I did not find any 
> > reference to "-mno-eabi", so now I am a bit confused: Where did 
> > you find, that gcc would provide non-eabi code? 
> > 
> > Any hints welcome...
> 
> OK, I'll try to explain.
> 
> I am referring to the powerpc-rtems in gcc-3.0.x and gcc-3.1 prereleases
> (gcc's CVS gcc-3_1-branch) and to RTEMS in OAR's CVS. I have not checked
> gcc-2.95.x.
> 
> To put it into one sentence: 
> 
> I assume gcc-3.x to use the the sysv-abi by default, while RTEMS
> internally seems to be using inconsistent, implict, hard-coded
> assumptions on the ABI.
> 
> 
> The details:
> 
> 1. All powerpc-rtems-gcc 's multilibs are build with
> -mrelocatable-lib -mno-eabi -mstrict-align
> 
> # powerpc-rtems-gcc --print-multi-lib   
> .;@mrelocatable-lib at mno-eabi@mstrict-align
> m403;@mcpu=403 at mrelocatable-lib@mno-eabi at mstrict-align
> m505;@mcpu=505 at mrelocatable-lib@mno-eabi at mstrict-align
> m601;@mcpu=601 at mrelocatable-lib@mno-eabi at mstrict-align
> m602;@mcpu=602 at mrelocatable-lib@mno-eabi at mstrict-align
> m603;@mcpu=603 at mrelocatable-lib@mno-eabi at mstrict-align
> m603e;@mcpu=603e at mrelocatable-lib@mno-eabi at mstrict-align
> m604;@mcpu=604 at mrelocatable-lib@mno-eabi at mstrict-align
> m750;@mcpu=750 at mrelocatable-lib@mno-eabi at mstrict-align
> m821;@mcpu=821 at mrelocatable-lib@mno-eabi at mstrict-align
> m860;@mcpu=860 at mrelocatable-lib@mno-eabi at mstrict-align
> nof;@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
> m403/roe;@mcpu=403 at D_OLD_EXCEPTIONS@mrelocatable-lib at mno-eabi@mstrict-align
> m505/roe;@mcpu=505 at D_OLD_EXCEPTIONS@mrelocatable-lib at mno-eabi@mstrict-align
> m601/roe;@mcpu=601 at D_OLD_EXCEPTIONS@mrelocatable-lib at mno-eabi@mstrict-align
> m601/nof;@mcpu=601 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> m601/roe/nof;@mcpu=601 at D_OLD_EXCEPTIONS@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
> m602/roe;@mcpu=602 at D_OLD_EXCEPTIONS@mrelocatable-lib at mno-eabi@mstrict-align
> m602/nof;@mcpu=602 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> m602/roe/nof;@mcpu=602 at D_OLD_EXCEPTIONS@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
> m603/roe;@mcpu=603 at D_OLD_EXCEPTIONS@mrelocatable-lib at mno-eabi@mstrict-align
> m603/nof;@mcpu=603 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> m603/roe/nof;@mcpu=603 at D_OLD_EXCEPTIONS@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
> m603e/mpc8260;@mcpu=603e at Dmpc8260@mrelocatable-lib at mno-eabi@mstrict-align
> m603e/roe;@mcpu=603e at D_OLD_EXCEPTIONS@mrelocatable-lib at mno-eabi@mstrict-align
> m603e/nof;@mcpu=603e at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> m603e/roe/nof;@mcpu=603e at D_OLD_EXCEPTIONS@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
> m603e/mpc8260/nof;@mcpu=603e at Dmpc8260@msoft-float at mrelocatable-lib@mno-eabi at mstrict-align
> m604/nof;@mcpu=604 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> m750/nof;@mcpu=750 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> 
> => All multilibs (libc.a, libm.a etc.) are available in versions
> compiled with -mno-eabi. None of the multilibs is available without
> -mno-eabi.
> 
> The origin of this behaviour is this line (~line 13) from 
> gcc/config/rs6000/t-ppcgas
> ..
> MULTILIB_EXTRA_OPTS	= mrelocatable-lib mno-eabi mstrict-align
> ..
> rsp. its counterpart in gcc/config/rs6000/t-rtems if using my ppc-gcc
> patch (In the attachment below).
> 
> 
> 2. As far as I understand the source-code in gcc (rs6000/sysv4.h), the
> _implicit_ default is ABI_V4 (implicitly using -mcall-sysv).
> 
> # touch tmp.c
> # powerpc-rtems-gcc -v -c tmp.c
> Reading specs from /opt/rtems/lib/gcc-lib/powerpc-rtems/3.1/specs
> Configured with: ../gcc-3.1/configure --target=powerpc-rtems
> --with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib
> --disable-nls --enable-version-specific-runtime-libs
> --enable-threads=rtems --prefix=/opt/rtems --enable-languages=c,c++
> Thread model: rtems
> gcc version 3.1 20020504 (prerelease)
>  /opt/rtems/lib/gcc-lib/powerpc-rtems/3.1/cc1 -lang-c -v -D__GNUC__=3
> -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -DPPC -D__rtems__ -D__PPC__
> -D__rtems__ -D__PPC -Asystem=rtems -Acpu=powerpc -Amachine=powerpc
> -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_CALL_SYSV -D_BIG_ENDIAN
> -D__BIG_ENDIAN__ -Amachine=bigendian -D_ARCH_PPC -Dmpc750 tmp.c -quiet
> -dumpbase tmp.c -version -o /tmp/ccPipnNu.s
> ..
> Note:
> * -D_CALL_SYSV
> 
> * MULTILIB_DEFAULTS in rs6000/sysv4.h (~line 1422)
> ..
> #define MULTILIB_DEFAULTS { "mbig", "mcall-sysv" }
> ..
> 
> * SUBTARGET_OVERRIDE_OPTIONS in rs6000/sysv4.h (~line 171)
> 
> 
> 
> 3. The RTEMS PPC_ABI_* defines.
> 
> These defines can be found scattered all over powerpc-rtems code inside
> of RTEMS:
> PPC_ABI_POWEROPEN
> PPC_ABI_GCC27
> PPC_ABI_SVR4
> PPC_ABI_EABI
> 
> Here one question is: 
> Which of them are actually used, which of them are historic (can any of
> them be abanoned) and why are they present at all (To support different
> ABIs/calling conventions in ASM, I assume - But why are they present at
> all)?
> 
> As far as I understand, POWEROPEN and GCC27 actually are hacks
> addressing obsolete versions of gcc.
> 
> Interestingly, they can only be found in OLD_EXCEPTION_HANDLING code:
> 
> # find -type f -exec grep -l ABI_POWER {} \;
> ./c/src/exec/score/cpu/powerpc/rtems/score/ppc.h
> ./c/src/exec/score/cpu/powerpc/rtems/old-exceptions/cpu.h
> ./c/src/exec/score/cpu/powerpc/asm.h
> ./c/src/lib/libbsp/powerpc/gen405/dlentry/dlentry.S
> ./c/src/lib/libbsp/powerpc/helas403/dlentry/dlentry.S
> ./c/src/lib/libbsp/powerpc/helas403/flashentry/flashentry.S
> ./c/src/lib/libbsp/powerpc/ppcn_60x/vectors/vectors.S
> ./c/src/lib/libbsp/powerpc/psim/vectors/vectors.S
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/rtems/score/ppc_offs.h
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/cpu.c
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/cpu_asm.S
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/irq_stub.S
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/rtems.S
> ./c/src/lib/libcpu/powerpc/ppc403/vectors/vectors.S
> ./c/src/lib/libcpu/powerpc/mpc505/vectors/vectors.S
> 
> # find -type f -exec grep -l ABI_GCC27 {} \;
> ./c/src/exec/score/cpu/powerpc/rtems/score/ppc.h
> ./c/src/exec/score/cpu/powerpc/rtems/old-exceptions/cpu.h
> ./c/src/lib/libbsp/powerpc/ppcn_60x/vectors/vectors.S
> ./c/src/lib/libbsp/powerpc/psim/vectors/vectors.S
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/rtems/score/ppc_offs.h
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/cpu.c
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/cpu_asm.S
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/irq_stub.S
> ./c/src/lib/libbsp/powerpc/support/old_exception_processing/rtems.S
> ./c/src/lib/libcpu/powerpc/ppc403/vectors/vectors.S
> ./c/src/lib/libcpu/powerpc/mpc505/vectors/vectors.S
> 
> If this holds, they probably can be removed (Obsolete versions of gcc,
> only used in depredicated parts of the code).
> 
> Yesterday, Joel assumed this:
> > Based upon
> > the description, I would say that the old exception code
> > tried to support real EABI but the new exception code doesn't.
> 
> If this assumption/statement holds, then RTEMS' multilib support in gcc
> (t-rtems) needs to be redesigned, e.g. to let
> old-exceptions imply -meabi
> and to let
> new-exceptions imply -mno-eabi
> 
> If so, then why this inconsistency? History?
> 
> The next question is: Why does RTEMS-gcc apply sysv4.h at all? 
> sysv4.h seems utterly complex to me, but I am not enough knowledgeable
> about the powerpc to have an opinion on this :(
> Anyway, sysv4.h seems to be applied by most other OSs (incl. linux and
> VxWorks), so the reason for using it might just be consistency with
> other OSes.
> 
> 
> Ralf
> 
> PS.: I am confused about all this and am having doubts on the "ABI*"
> support in RTEMS. Actually, I am wondering how this all works. :(
> 
> -- 
> Ralf Corsepius 
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999  
> http://www.faw.uni-ulm.de
> 

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_key.htm