Powerpc IRQ handling breaks strict EABI compliance

[Till Straumann]

Joel Sherrill wrote:
> 
> 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
> bsp_specs
> so this has no impact.  _Thread_Handler() can only use information
> provided
> to it by the compiler.

That's why I propose to have the _tool_ spec change
-D__USE_INIT_FINI__
to -D__USE_INIT_FINI__=value

If we want a BSP specific value - that's already in place:
__Thread_Handler() is not calling __init but _init which
is defined by the BSP specific linker script. At the expense of
having to fix this for each individual BSP, we could well
go this way:

__Thread_Handler() calls _init() [defined in BSP linkcmds]
It should check against a NULL value however!
The BSP could still check for compiler flags (using bsp_specs)
and tweak the value of _init accordingly ;-)

This is more flexible but it means that when we discover
something like the issue we are dealing with right now
probably all BSP linkcmds/bsp_specs need to be fixed.

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

AFAIK (and I know little about multilibs), multilibs are CPU specific,
whereas EABI is an ABI, so I'd assume these issues are somewhat
orthogonal.

Regarding the mixing of eabi and no-eabi code: note that (as it has
been pointed by Sergei) there is also the msdata flag which controls
the _use_ of R2/R13 and the _sections_ where short data objects are
put by the compiler (and the maximal size defining what 'short data' is)
OTOH, -meabi/-mno-eabi controls stack alignment (8 vs. 16) and
whether __eabi() is executed at init time (although, unlike its info
page claims, gcc seems to always call __eabi from main).

Note that it may or may not be possible to link together modules
who were compiled with differing -msdata settings. You should
get a linker error if you chose an invalid setting.

Suppose, e.g. a.c defines an integer variable a, module b.c accesses
it. Consider linking a.o with b.o:

a) a.c compiled with -msdata=none, b.c with -msdata=sysv

     ---> failure; b expects the variable 'a' to be in the
          .sdata section - a.o has it in its '.data' section.

b) a.c compiled with no '-msdata' flag, b.c with -msdata=eabi

    ---> works; b.o generated with a special relocation record
         who resolves to either a R2 access to .sdata2 or R13
         access to .sdata, depending on where the linker finds
         the 'a' variable. Because 'a.c' was compiled with no
         '-msdata' flag, 'a' ended up in .sdata (although code
         inside a.c would make no use of R2/R13 [unlike when
         a.c would have been compiled with -msdata=eabi or
         -msdata=sysv].

Conclusion: you have to know what you are doing ;-),
RTM (info gcc, SYSV/EABI docs). I any case, prior to
using any of these:
    -msdata
    -msdata=eabi
    -msdata=sysv
    -msdata=use
    -mrelocatable (__eabi relocates GOTs)
    C++ static constructors
    C++ exceptions
    ...
you better call __eabi()

-- Till.

> 
> 
>>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
> __init()
> 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
> tools
> and rtems-XXX/cpukit -- no BSP influence allowed.
> 
> 
>>-- Till
> 
>