Powerpc IRQ handling breaks strict EABI compliance

[Joel Sherrill]

Joel Sherrill wrote:
> 
> 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?

I have a simple program "main(){}".  It calls __eabi() regardless of
how that switch is set.  
 
> It is probably trivial to conditionally compile to make the PPC call
> __eabi() instead of __init() if we know when precisely to do it.

I think conditionally selecting __eabi() as the init function instead
of _init() on the PowerPC would be the simplest solution for now.  It
requires no tool or BSP specs changes.  Plus bsp_specs have no change
at compile time on any code in cpukit.  cpukit is compiled completely
independently of the BSP.

Try just calling __eabi instead of _init on the PPC and let us know.
It should be an easy change.


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

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