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

[till]

Sergei.

Thanks for shedding some more light on this. Could you clarify some more 
points?
 - 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.                       
                              ***
 - 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.
 - the current behavior (RTEMS calling __init from the ThreadHandler) is 
wrong. An application
   using main (and hence calling __eabi) has C++ constructors called twice.
 - 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.
 - 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
   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.

 - do you see any other difference between -meabi and -mno-eabi besides the
   stack alignment requirement? Is there any problem in real life 
resulting from
    misalignment?

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.

-- Till

Sergei Organov wrote:

>For me it seems that discussion of the issues went too far in two other
>related threads, so I decided to start from scratch.
>
>First of all, let's explicitly separate two different issues: (1) low-level
>initialization that is ABI dependent and (2) calling of C++ constructors.
>
>The main difference between them is that these two steps should be done at
>*different* stages of RTEMS initialization sequence. While (2) could be done
>rather late (e.g., at the point RTEMS currently calls _init()), the (1) should
>be done before the first C/C++ routine is called. This observation immediately
>makes it apparent that __eabi() routine provided by gcc is useless for RTEMS
>as __eabi() does these two steps sequentially [1].
>
>To properly support SYSV-ABI/EABI from initialization point of view, the
>following actions could be taken:
>
>1. RTEMS should either provide empty __eabi() as a replacement of gcc-provided
>   __eabi() or, alternatively, undefine NAME__MAIN (and, maybe, INOVKE__main)
>   in gcc/config/rs6000/rtems.h file to prevent call to __eabi() from main()
>   by gcc.
>
>2. RTEMS should call __init() directly (not through __eabi()) when it's time
>   to invoke C++ constructors.
>
>3. RTEMS (in fact, BSP) should make ABI-dependent initialization itself in its
>   asm startup code before the first C routine is called. This is the place
>   where actual code could depend on particular ABI selected. Fortunately, it
>   seems that in the PowerPC case it's safe to just always load r13 and r2
>   with the values of linker-defined symbols, _SDA_BASE_ and _SDA2_BASE_,
>   respectively, no matter what ABI is actually in use.
>
>4. All the BSPs that implement (3) should define _SDA_BASE_ and _SDA2_BASE_ in
>   their linker scripts. Those that don't wish to actually support SYSV/EABI
>   conventions could define them to 0.
>
>Disclaimer: The above doesn't even try to address issues with relocations the
>__eabi() makes. I suppose they are useless unless somebody wants to link and
>load RTEMS application as relocatable code. Anyway, these issues could be
>discussed separately, I hope.
>
>[1] In fact I think the name of __eabi() function is somewhat misleading, as
>it does a lot of thing only a few of which are EABI-specific. Maybe that's why
>gcc now calls __eabi() no matter what ABI is actually selected by switches.
>