More EABI/C++ issues (was Re: EABI and C++)

[Sergei Organov]

Till Straumann <strauman at SLAC.Stanford.EDU> writes:
> Gary.
> 
> You actually raised an interesting question and I CC to the list.
> We were just discussing other EABI related things and your
> issue fits in perfectly.
> 
> Gary brought to my attention that I had previously investigated
> on how GCC/RTEMS deal with EABI/C/C++ initialization. What
> I found a while ago is appended below.
> 
> The current version of GCC/RTEMS seems to follow the path described
> under 2d) below:
> 
> RTEMS (if the BSP has _USE_INIT_FINI_ defined) calls '__init()' at
> an early stage. 'bsp_specs' seem to have been updated to include
> crtbegin/crtend when linking an application. Hence, all C++ static
> constructors will be called by __init(). Exception handler frames
> are also taken care of as well.
> 
> However, the behavior still has some flaws:
> 
>   - If we want to support EABI, RTEMS should not call __init()
>     but __eabi() (who ends up branching to __init()).

I think you are right. The good news are that __eabi() has protection code and
therefore could be safely invoked multiple times, so RTEMS may call it
whenever it wants before main() -- this will effectively make gcc-embedded
call to __eabi from main() a no-op.

>   - Doesn't the current GCC actually use EABI (msdata) and hence
>     rely on __eabi() being properly called?

Good question. It seems there is some confusion here though. The .sdata/.sbss
sections are part of *both* SYSV ABI *and* EABI, so R13 should be correctly
initialized to point to these sections even without EABI. EABI adds two more
small sections, .sdata2/.sbss2, for read-only small data and requirement to
initialize R2 to point to these sections.

Now what gcc does by default. It does generate .sdata/.sbss sections, but the
code generated to access variables in these sections doesn't use R13 -- they
are accessed as if they were in .data/.bss. Gcc begins to actually *use* R13
if -msdata=sysv switch is specified. So the conclusion is: by default gcc
makes code that doesn't depend on proper initialization of R13/R2.

Back to EABI. As soon as -meabi is specified, gcc starts to generate code
that *uses* both R13 and R2. According to the documentation, it would also
embed a call to __eabi() only when -meabi is specified. However I've just
noticed that gcc-3.3(prerelease) embeds the call to __eabi into main() always,
even when -mno-eabi is explicitly specified. This well maybe a bug in gcc-3.3
so RTEMS shouldn't rely on __eabi to be always called from main().

-- 
Sergei.