[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More EABI/C++ issues (was Re: EABI and C++)
- Date: Wed, 12 Feb 2003 09:14:50 -0600
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: More EABI/C++ issues (was Re: EABI and C++)
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().
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