Powerpc IRQ handling breaks strict EABI compliance

[Joel Sherrill]

Till Straumann wrote:
> 
> gregory.menke at gsfc.nasa.gov wrote:
> > till writes:
> >  > Joel Sherrill wrote:
> >  >
> >  > >
> >  > >Till Straumann wrote:
> >  > >
> >  > >>Joel Sherrill wrote:
> >  > >>
> >  > >>>Sergei Organov wrote:
> >  > >>>
> >  > >>>>Till Straumann <strauman at SLAC.Stanford.EDU> writes:
> >  > >>>>
> >  > >>>>>OK, I fixed the motorola/shared BSP to not clobber R2/R13 anymore.
> >  > >>>>>However, the question remains:
> >  > >>>>>
> >  > >>>>> - who is responsible for the setup (calling __eabi()) ?
> >  > >>>>>   RTEMS or application code?
> >  > >>>>>
> >  > >>>>It's main() that when compiled with corresponding gcc switches automatically
> >  > >>>>invokes __eabi(). It basically only setups R2/R13. BTW, R13 is being used even
> >  > >>>>without EABI -- R13 usage is part of SYSV ABI which EABI is derived from.
> >  > >>>>
> >  > >>>>This brings another interesting problem. In older days of RTEMS the 'main' was
> >  > >>>>part of RTEMS, not the part of application code, so it was invoked very early
> >  > >>>>and thus all RTEMS/BSP initialization went after __eabi() has been called.
> >  > >>>>AFAIK, now situation is different and __eabi() will be invoked too late. It
> >  > >>>>means that RTEMS startup code should invoke __eabi() (or setup R13/R2 itself)
> >  > >>>>for things to work correctly as C startup/initialization code compiled for
> >  > >>>>SYSV ABI/EABI will already rely on correct values in R2/R13.
> >  > >>>>
> >  > >>>
> >  > >>>RTEMS now ensures that the first thread to execute invokes the
> >  > >>>appropriate
> >  > >>>routine for that gcc target to run global constructors.  The
> >  > >>>powerpc-rtems
> >  > >>>gcc target is noted as being an init/fini target so it will call
> >  > >>>_init().
> >  > >>>
> >  > >>>
> >  > >>OK, I saw that bsp_specs have been updated to include crtbegin/crtend.
> >  > >>However, how do you prevent from initialization happening twice if
> >  > >>the user uses 'main'?
> >  > >>
> >  > >
> >  > >My memory is that the __init functions have a boolean variable that
> >  > >say they have been executed already.
> >  > >
> >  >
> >  > I disassembled some code and it doesn't look like there is such a flag.
> >  > __eabi() implements
> >  > such a guard, however and so does gcc's 'main' header (on architectures
> >  > who don't have
> >  > ..init/.fini sections) before calling __init(). (I still could be wrong...)
> >  >
> >
> > The interlock can be seen in _Thread_Handler at about line 111,
> > score/cpu/threadhandler.c, rtems-ss-20030128
> >
> > As implemented, the init task calls the constructors just before
> > jumping to userspace.  Once init has called _init_fini, the flag skips
> > future invocations for all tasks created later on.
> 
> Yes, but on PPC this behavior is still wrong (the _Thread_Handler should
> invoke __eabi(), not __init9) on PPC-eabi):
> 
> a) __eabi() does other initialization before calling __init()
> b) if the user (e.g. by means of providing a 'main' [who
>     implicitely calls __eabi()]) later calls __eabi(), __init()
>     will still be executed twice, because __init() has no guarding
>     flag and __eabi() doesn't care about the one private to the
>     _Thread_Handler

I agree with the analysis but don't see any indication that gcc tells
us if -meabi or -mno-eabi is in use.  DO you have a simple program that
I can compile with powerpc-eabi-gcc and see what it does by comparison?

It is probably trivial to conditionally compile to make the PPC call 
__eabi() instead of __init() if we know when precisely to do it.

> -- Till
> 
> >
> > The interlock logic seems a little tortured, but I imagine there is or
> > was a reason for it...
> >
> > __USE_MAIN__ can be made to work, init_fini seems the more current
> > approach.
> >
> > Gregm
> >

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