Powerpc IRQ handling breaks strict EABI compliance

[Till Straumann]

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

-- Till.

>>What I want to tell is that using of SYSV ABI/EABI indeed makes code smaller
>>and faster, so it'd be fine if PPC port of RTEMS starts to support it again
>>(the old RTEMS 3.x code did support it, BTW).
> 
> 
> The application owning main() was generally viewed as an improvement. :)
> 
> In the olden days, main() happened too early and drivers were not yet
> initialized.
> This lead to situations where global constructors could not print or do
> other operations.
>  
> 
>>--
>>Sergei.
> 
>