Powerpc IRQ handling breaks strict EABI compliance

[gregory.menke at gsfc.nasa.gov]

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.

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