Powerpc IRQ handling breaks strict EABI compliance
Joel Sherrill
joel.sherrill at OARcorp.com
Tue Feb 11 15:01:55 UTC 2003
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().
> 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.
--
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
More information about the users
mailing list