Powerpc IRQ handling breaks strict EABI compliance

[Ralf Corsepius]

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

Ralf