Powerpc IRQ handling breaks strict EABI compliance

[Ralf Corsepius]

Am Don, 2003-02-13 um 15.41 schrieb 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.
Exactly.

Further _all_ -mno-eabi compiled programs try to link against __eabi.

This is why I think eabi.h should be removed from the
powerpc-rtems-clause in config.gcc.

> 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. 
Another solution would be to dictate "THE ABI powerpc-rtems uses".

You would not play with ABI-formats on Linux or Solaris, wouldn't you?
You simple would have to take what the manufacture dictates.

I am no expert on the ppc, so can't judge what is THE ABI to use, or if
one ABI is more useful for this or the other CPU-variant

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

That's why I say, we should settle this by drawing a decision.

We could implement a powerpc-rtemseabi-gcc and a powerpc-rtemsnoeabi-gcc
and reduce the mount of multilibs by assigning a each of the current
powerpc-cpus to one of each ABI.

However, I don't know if this would be reasonable (To me, the powerpc
multilib-ing scheme already is insane ;) )

Ralf