Powerpc IRQ handling breaks strict EABI compliance

[Joel Sherrill]

Sergei Organov wrote:
> 
> Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:
> [...]
> > > 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.
> 
> But __eabi() surprisingly has almost nothing to do with EABI itself. I.e., it
> does a lot of things and only part of them are EABI-specific :-( I begin to
> believe that always calling __eabi() is intentional decision of gcc
> developers. However, please take a look at my separate post about the issue to
> see why __eabi() is useless for RTEMS anyway.

I agree with your analysis.   The r2/r13 init needs to happen much
earlier
than constructors can be executed.  

So the simplest solution (to me anyway) is:

  + bsp assembly startup initializes r2/r13 possibly using common code
derived
    from __eabi without the call to _init.
  + call _init from _Threaad_Handler

Longer term, we can switch the toolset from non-EABI to EABI if that is
desirable.

> [...]
> 
> > However, I don't know if this would be reasonable (To me, the powerpc
> > multilib-ing scheme already is insane ;) )
> 
> I'm second on this. Or I was first, then you are second :)

As Ralf knows, the issue is bound up on having any support for old
exceptions
versus new exception processing.  So updating all remaining old
exception 
powerpc BSPs to the new exception processing model would eliminate a 
big multiplier. 

> --
> Sergei.

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