[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Powerpc IRQ handling breaks strict EABI compliance

Till Straumann wrote:
> Joel.
> >>
> >>I agree with the analysis but don't see any indication that gcc tells
> >>us if -meabi or -mno-eabi is in use.  DO you have a simple program that
> >>I can compile with powerpc-eabi-gcc and see what it does by comparison?
> >
> >
> > I have a simple program "main(){}".  It calls __eabi() regardless of
> > how that switch is set.
> >
> Yes, we all found that - it's not clear though if this is a bug or a
> feature. Note that I also checked against linker magic (the linker
> could theoretically initialize __eabi()'s 'already_done' flag to
> '1' if -mno-eabi is specified. This seems not to be the case, however.
> >
> >>It is probably trivial to conditionally compile to make the PPC call
> >>__eabi() instead of __init() if we know when precisely to do it.
> Yeah - I still like my approach (described in another post) better:
> just give __USE_INIT_FINI__ a value [requires a tool 'spec' change,
> however].

But I repeat that the code under cpukit is NOT compiled using the
so this has no impact.  _Thread_Handler() can only use information
to it by the compiler.

Is it safe to mix eabi and no-eabi code?  I don't understand the
naming of the multilibs and can't tell whether it is OK or not.

> I just did some other test:
> I compiled
>     const        int svar=0xdeadbeef;
>     extern const int ext_svar;
>     int test(void) { return ext_svar + svar; }
> with the command
>     powerpc-rtems-gcc -O -c -msdata=xxx test.c
>   - if I use -msdata=default or -msdata=eabi
>      --> svar ends up in the .sdata2 section
>      --> ext_svar ends up being accessed using R2
>          (actually, it is a R_PPC_EMB_SDA21 reloc
>           which is resolved by the linker into
>           R2 + an offset)
>   - if I use -msdata=sysv
>      --> svar ends up in the .sdata section
>      --> ext_svar is accessed via R13
>   - if I use -msdata=none
>      --> svar ends up in the .rodata section
>      --> ext_svar is accessed via a normal relocation
>   - if I use no '-msdata' option at all
>      --> svar ends up in the .sdata section
>      --> ext_svar is accessed via a normal relocation
> This indicates, that powerpc-rtems indeed has the
> -meabi option on by default.

Then for sure, as a minimum, _Thread_Handler() should call __eabi() not
on the powerpc-rtems target to be correct.  A more complex solution can 
be discussed but will have to consider that it is a contract between the
and rtems-XXX/cpukit -- no BSP influence allowed.

> -- Till

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