Powerpc IRQ handling breaks strict EABI compliance

[Sergei Organov]

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.

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

-- 
Sergei.