Powerpc IRQ handling breaks strict EABI compliance

[Joel Sherrill]

Sergei Organov wrote:
> 
> Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:
> [...]
> > > I'm second on this. Or I was first, then you are second :)
> > I am the author of this powerpc multilib-ing scheme ;)
> 
> I meant an order of posts in this particular thread ;)
> 
> >
> > However, this only is a reflection of what is really used inside RTEMS
> > powerpc-port - I had tried to minimize it, but ..
> 
> Looking at t-rtems file it's obvious you indeed tried rather hard.
> 
> > The origin of this insanity is the cascades/plethora of defines being
> > using in the powerpc's cpu.h and the split into old/new-exception
> > processing. If some of these defines could be eliminated (esp.
> > old/new-exception-handling) this amount of multilibs could be minimized.
> 
> I definitely agree with you that current state of PPC BSPs as a whole is total
> mess. I myself dislike quite a few decisions made in the new exception
> processing, but for the sake of clarity, I'd just remove all the BSPs that
> don't support new exception processing from multilib variants. If somebody
> (like me) wants to use them, he can build a tool-chain with customized
> t-rtems. Besides, if I remember correctly, that's what Joel said will
> be done when switching to multilib has been considered.

A solution Ralf and I discussed when the multilib work was done was 
have a separate powerpc target name for old exception BSPs or a
configure
time option to rtems.  That would also implicitly decouple them.

Ralf would it be possible to have a configure flag to RTEMS which picked
the exception model and built only that portion of the BSPs?  Then
we could drop the new/old exceptions as a multilib variant.   Would this
work?

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