PPC initialization (SYSV-ABI/EABI/C++ issues).

[gregory.menke at gsfc.nasa.gov]

till writes:
 > Sergei.
 > 
 > Thanks for shedding some more light on this. Could you clarify some more 
 > points?
 >  - R13 should be set up regardless of RTEMS using EABI or SYSV, right?
 >    *** even if RTEMS is considered to be non-EABI, most BSPs are 
 > probably ***
 >    *** broken as they currently fail to setup R13.                       
 >                               ***
 >  - it seems to me that R2/R13 don't really have to be set before _any_ C 
 > code is executed
 >    but they must be set before any code compiled with 
 > -msdata=eabi/sysv/use is called.
 >  - the current behavior (RTEMS calling __init from the ThreadHandler) is 
 > wrong. An application
 >    using main (and hence calling __eabi) has C++ constructors called twice.
 >  - substituting __init in ThreadHandler by __eabi is wrong but it should 
 > work as long as
 >     RTEMS does not _use_ R2 or R13 prior to executing __eabi.
 >  - the proper sequence would be:
 >      [0) if the relocation features are needed, relocation has to be 
 > performed first ]
 >      1) initialize R13 / R2 (using linker magic as you proposed) as 
 > early as possible
 >      2) initialize newlib
 >      3) call C++ constructors once ( __init from ThreadHandler)
 >      4) prevent app 'main' from calling __eabi
 >    That way, RTEMS itself and/or newlib could even benefit from the 
 > short data areas
 >    (requires building with -msdata=eabi or sysv)
 > 
 >    NOTE: all of this can easily be achieved if __eabi can be prevented 
 > from branching
 >                 to __init. The BSP would then just call __eabi() at an 
 > early stage and
 >                 the ThreadHandler calls __init as it has always done.



Thanks for summarizing, I still wasn't quite getting it.  _eabi()'s
behavior seems more of a gcc issue than something that RTEMS must deal
with.  I think a gcc tweak to allow eabi() and init() do be optionally
decoupled is a better approach in the long run.  I think the
constructors are best called from ThreadHandler in any case because
the init task state is defined at that point and there could be FP
enable, stack or environment issues of consequence to the
constructors.

Is anyone aware of the genesis of eabi()?  For instance perhaps its
behavior was arranged for convienence on some platform and might
reasonably be enhanced.

Gregm