RTEMS powerpc eabi? PR195

Sergei Organov osv at javad.ru
Thu May 23 08:17:15 UTC 2002 

Gentlemen,

AFAIK, libraries built with -mno-eabi are compatible with the user code that
uses EABI, so apparently 'gcc' guys have decided to compile all the libraries
in the 'no-eabi' mode so that they could be used by both the SVR4 ABI and the
EABI code.

Personally, I always change the gcc multilib settings to build separate set of 
true EABI libraries (and to decrease number of variants being built as I don't
need all of them). But this is just an optimization.

In addition, powerpc RTEMS has been always compiled in the no-eabi mode as
well. To compile it in full EABI mode, two more switches, -meabi and
-msdata=eabi, are required (maybe the latter switch is actually not required
as by default -msdata should be equal to 'default' for selected ABI, which in
turn is equal to 'eabi' for EABI).

BR,
Sergei Organov.

"Thomas Doerfler" <Thomas.Doerfler at imd-systems.de> writes:
> 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

More information about the users mailing list