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

[Joel Sherrill]

As an aside, I BEG that when this issue is figured out that
someone submit a patch to the calling conventions section
of the PowerPC supplement so it is captured forever.

Sergei Organov wrote:
> 
> 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.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985