Powerpc IRQ handling breaks strict EABI compliance

[Till Straumann]

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

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.

-- Till