RTEMS powerpc eabi? PR195
Thomas Doerfler
Thomas.Doerfler at imd-systems.de
Mon Jun 10 19:40:25 UTC 2002
Hi,
so finally I have come to a conclusion regarding the PowerPC
EABI/SVR4 confusion:
Concerning libraries, there is only one difference between the
EABi and SVR4 ABI for GCC: The data type "long double"
requires a 8 byte alignment under EABI and a 16 byte alignment
for SVR4 ABI. For library usage, this would only affect
functions, which pass a "long double" at a non-16-byte-aligned
position in a data structure.
Although this might lead to potential truble, I think this
kind of parameter passing will not occure when translating
RTEMS and its supporting libraries for PowerPC. So, to come to
an end:
Using the setting "noeabi" to generate multilibs for PowerPC
is acceptable, even when the compiler and linker acutally use
the EABI conventions.
bye,
Thomas.
> 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
--------------------------------------------
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