Powerpc IRQ handling breaks strict EABI compliance

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Don, 2003-02-13 um 01.13 schrieb Till Straumann:
> > Joel Sherrill wrote:
> > >
> > > Till Straumann wrote:
> > >
> > >>Joel.
> > >>
> > >>
> > >>>>I agree with the analysis but don't see any indication that gcc tells
> > >>>>us if -meabi or -mno-eabi is in use.
> 
> Note that all rtems-powerpc-gcc multilib variants currently apply
> -mno-eabi.
> 
> I've never understood how -meabi is supposed to work in this context,
> but I'm not a powerpc expert and had been told it would work when I had
> asked about it (There is a PR on this in GNATS)
> 
> >   DO you have a simple program that
> > >>>>I can compile with powerpc-eabi-gcc and see what it does by comparison?
> > >>>
> > >>>
> > >>>I have a simple program "main(){}".  It calls __eabi() regardless of
> > >>>how that switch is set.
> [Referring to gcc's source code]
> 
> Have a look at NAME__MAIN in gcc/config/rs6000/eabi.*
> 
> => powerpc-eabi always uses __eabi instead of __main, cf.
> grep NAME__MAIN gcc/*
> and
> grep NAME__MAIN gcc/config/*/*
> 
> powerpc-rtems-gcc applies eabi.h (cf. gcc/config.gcc)
> => powerpc-rtems-gcc always applies __eabi instead of __main.
> 
> => IMHO, a potential fix would be
> 
> 1. to take out eabi.h of the powerpc-rtems rule in config.gcc (Which, to
> my understanding, would mean to abandon eabi support in powerpc-rtems)
> 
> 2. to implement a powerpc-rtemsaabi gcc, which then could rely on
> __eabi.
> 
> > >>>
> > >>
> > >>Yes, we all found that - it's not clear though if this is a bug or a
> > >>feature. Note that I also checked against linker magic (the linker
> > >>could theoretically initialize __eabi()'s 'already_done' flag to
> > >>'1' if -mno-eabi is specified. This seems not to be the case, however.
> > >>
> > >>
> > >>>>It is probably trivial to conditionally compile to make the PPC call
> > >>>>__eabi() instead of __init() if we know when precisely to do it.
> > >>>
> > >>Yeah - I still like my approach (described in another post) better:
> > >>just give __USE_INIT_FINI__ a value [requires a tool 'spec' change,
> > >>however].
> > >
> > >
> > > But I repeat that the code under cpukit is NOT compiled using the
> > > bsp_specs
> > > so this has no impact.  _Thread_Handler() can only use information
> > > provided
> > > to it by the compiler.
> >
> > That's why I propose to have the _tool_ spec change
> > -D__USE_INIT_FINI__
> > to -D__USE_INIT_FINI__=value
> The proper way to implement changes to gcc's specs is to patch gcc.
> 
> I.e. instead of implementing your proposal, we could patch gcc to
> directly provide a define if using -meabi.
> 
> The only problem is where in gcc/config/rs6000/* to add it. One
> possiblity is to add the line below to CPP_OS_RTEMS_SPEC in
> gcc/config/rs6000/sysv4.h:
> 
> #define CPP_OS_RTEMS_SPEC \
> %{meabi: -D__EABI__} \
> ...
> 
> > If we want a BSP specific value - that's already in place:
> > __Thread_Handler() is not calling __init but _init which
> > is defined by the BSP specific linker script. At the expense of
> > having to fix this for each individual BSP, we could well
> > go this way:
> >
> > __Thread_Handler() calls _init() [defined in BSP linkcmds]
> > It should check against a NULL value however!
> > The BSP could still check for compiler flags (using bsp_specs)
> > and tweak the value of _init accordingly ;-)
> >
> > This is more flexible but it means that when we discover
> > something like the issue we are dealing with right now
> > probably all BSP linkcmds/bsp_specs need to be fixed.
> >
> > >
> > > Is it safe to mix eabi and no-eabi code?  I don't understand the
> > > naming of the multilibs and can't tell whether it is OK or not.
> >
> > AFAIK (and I know little about multilibs), multilibs are CPU specific,
> > whereas EABI is an ABI, so I'd assume these issues are somewhat
> > orthogonal.
> No, multilibs are not necessarily CPU specific.
> 
> >>From the compiler's view, multilibs is a mapping of a set of compilation
> flags into a library search-path.
> 
> # powerpc-rtems-gcc --print-multi-lib
> .;@mrelocatable-lib at mno-eabi@mstrict-align
> [...]
> m750/nof;@mcpu=750 at msoft-float@mrelocatable-lib at mno-eabi@mstrict-align
> 
> The left-hand side (left of the ';' in each line) specifies the
> directory, the right-hand side specifies the set of compilation flags.
> 
> These sets of compilation flags basically are arbitrary and therefore
> can be chosen at will to a large extend.
> 
> > Regarding the mixing of eabi and no-eabi code:
> ..
> > >This indicates, that powerpc-rtems indeed has the
> > > -meabi option on by default.
> The set of default flags is this:
> # powerpc-rtems-gcc --print-multi-lib
> .;@mrelocatable-lib at mno-eabi@mstrict-align
> 
> I think, the cause of pulling eabi related sections is using eabi.h in
> config.gcc.
> 
> I am not sure if this qualifies as a bug in powerpc-rtems-gcc, in gcc in
> general, or as a bug in RTEMS (RTEMS __main/main-handling interfering
> with the powerpc-eabi-gcc expectations on __main/__eabi).

My reading of the output of powerpc-rtems-gcc --print-multi-lib shows
that
there are no libraries for -meabi which means there is no valid way to
link an EABI program.

I am beginning to believe (1) this will not be addressed in 4.6.0 
and (2) that a 2nd toolset for EABI may be needed.  The C/C++ 
powerpc-rtems RPM is already 55 MB for C and 70 MB for C++ !  We 
simply can't make it any larger to have EABI and no EABI libraries.

> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985