PPC initialization (SYSV-ABI/EABI/C++ issues).

[Sergei Organov]

till <strauman at slac.stanford.edu> writes:
> Sergei.
> 
> Thanks for shedding some more light on this. Could you clarify some more
> points?

At least I can try to :-)

> 
>  - R13 should be set up regardless of RTEMS using EABI or SYSV, right?
>    *** even if RTEMS is considered to be non-EABI, most BSPs are probably ***
>    *** broken as they currently fail to setup R13. ***

No, I don't think so. By default ppc-rtems-gcc produces code that doesn't use
R13 to access variables in the .sdata/.sbss, though it does put variables of
the size less than or equal to 8 bytes to these sections.

> 
>  - it seems to me that R2/R13 don't really have to be set before _any_ C
>    code is executed but they must be set before any code compiled with
>    -msdata=eabi/sysv/use is called.

Yes, indeed. For simplicity I've supposed that all the C/C++ code is compiled
with the same flags, that's why I said "any".

> 
>  - the current behavior (RTEMS calling __init from the ThreadHandler) is
>    wrong. An application using main (and hence calling __eabi) has C++
>    constructors called twice.

Yes, I think so.

>  - substituting __init in ThreadHandler by __eabi is wrong but it should work
>    as long as RTEMS does not _use_ R2 or R13 prior to executing __eabi.

Yes. But much simpler fix, IMHO, is just to provide empty __eabi() (e.g., in
start.S) instead of substituting __init by __eabi. Though unlike substitution
it won't initialize r2/r13 at all, the "calling constructors twice" problem is
solved.

>  - the proper sequence would be:
>      [0) if the relocation features are needed, relocation has to be
>      performed first ]
>      1) initialize R13 / R2 (using linker magic as you proposed) as early as
>         possible
>      2) initialize newlib
>      3) call C++ constructors once ( __init from ThreadHandler)
>      4) prevent app 'main' from calling __eabi

Or provide empty __eabi().

>    That way, RTEMS itself and/or newlib could even benefit from the short
>    data areas (requires building with -msdata=eabi or sysv)
> 
>    NOTE: all of this can easily be achieved if __eabi can be prevented from
>    branching to __init. The BSP would then just call __eabi() at an early
>    stage and the ThreadHandler calls __init as it has always done.

Yes. I even think it'd be the best solution to fix gcc/config/rs6000/eabi.asm
so that it has a separate global routine that performs low-level part of what
__eabi() currently does. For compatibility, __eabi() itself could then just
call this routine and then __init(). RTEMS will then arrange to never call
__eabi(), and BSP will call this new low-level initialization routine ASAP,
and then __init() from ThreadHandler.

If it's not an option to change gcc, then PPC port can provide its own
low-level initialization routine that will be called by all BSPs start.S files
(the routine may also include such common things as cleanup of .bss/.sbss and
copying of .data from ROM to RAM).

> 
>  - do you see any other difference between -meabi and -mno-eabi besides the
>    stack alignment requirement?

I talked about differences between '-meabi' and '-mno-eabi -msdata=eabi'. As
far as I remember, besides stack alignment, alignment of doubles also differs,
8 vs 16, respectively. The weaker alignment requirements of -meabi could
result in performance degradation on PPCs with 64-bit data bus when accessing
doubles, I think, but I don't have any numbers. On the other hand, weaker
stack alignment has potential benefit of more conservative stack usage.

> Is there any problem in real life resulting from misalignment?

Yes, when one passes a lot of arguments to a C routine and they begin to be
put on stack, there could be problems. I myself once found related problem
when RTEMS didn't align task stacks properly. The problem occurred when
printf() with a lot of arguments has been called.

Overall, I'd afraid to mix code with different alignment requirements in a
single application.

> 
> The way I see it now (given the fact that some changes, even in the
> toolchain, are necessary anyways), it seems that RTEMS should be declared to
> support EABI (as Joel proposed). Hopefully the multilib jungle can be
> reduced somewhat.
> 

It's my opinion as well.

-- 
Sergei.