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

[Sergei Organov]

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.

-- 
Sergei.