Powerpc IRQ handling breaks strict EABI compliance
joel.sherrill at OARcorp.com
Thu Feb 13 19:14:19 UTC 2003
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
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
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
More information about the users