More EABI/C++ issues (was Re: EABI and C++)
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Feb 12 15:13:57 UTC 2003
Till Straumann wrote:
>
> 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.
FWIW powerpc-rtems ensures that _USE_INIT_FINI_ is predefined by the
toolset. I believe that the gcc must specifically tell RTEMS what
initialization method to use. If this depends on knowing if
-meabi is set on the command line, then gcc needs to be patched to
make sure a cpp predefine indicates this setting. We have had to
fix other times gcc has an -m flag that doesn't trip a cpp define
so you can know whether or not some code generation mode is enabled.
So I would say that whatever gcc needs to have done, it should
set something indicating that and _Thread_Handler is still the
right place to do this.
Technically, any BSP setting _USE_INIT_FINI_ is covering up for
old toolsets that did not do the right thing.
> 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()).
> - Doesn't the current GCC actually use EABI (msdata) and hence
> rely on __eabi() being properly called?
> - Note that calling __eabi() after __init() has been executed
> (e.g. indirectly, by a user's 'main')
> will result in __init() being executed _twice_ (__eabi() seems
> to check against being called more than once, __init() does not).
>
> Conclusion:
> cpukit/score/src/threadhandler.c should NOT call __init() but
> an alias for a BSP specific initialization routine. On PPC, this
> should probably be __eabi().
>
> -- Till
>
> Gary R. Garrison wrote:
> > Absolutely no reason for you to be sorry - my thanks for your consideration
> > in replying!
> > I'm including the original HTML that I found. Thanks again for any further
> > information
> > you can provide.
> >
> > Gary
> >
> > ----- Original Message -----
> > From: "Till Straumann" <strauman at SLAC.Stanford.EDU>
> > To: "Gary R. Garrison" <g.r.garrison at cashsystemes.com>
> > Sent: Tuesday, February 11, 2003 12:41 AM
> > Subject: Re: EABI and C++
> >
> >
> >
> >>Gary.
> >>
> >>Sorry for the late reply - I'm a little swamped with email these days.
> >>Unfortunately, I can't recall what I wrote nor when or where I posted
> >>it. In order to avoid repeating the same things - could you, please send
> >>me a copy of the posting you refer to? Once I re-read that, it will
> >>be easier to address your question.
> >>
> >>Thanks
> >>
> >>-- Till.
> >>
> >>Gary R. Garrison wrote:
> >>
> >>>Having comme across a posting of yours explaining the relationship
> >>
> > between
> >
> >>>__eabi(), __main(), C++ and __init, I'm taking the liberty of
> >>>contacting you
> >>>
> >>>directly in my never ending search for information. Actually what I
> >>
> > would
> >
> >>>greatly appreciate is a simple push in the right direction. Where did
> >>>you find
> >>>
> >>>this information? I've successfully ported a Nucleus Plus PowerPC
> >>
> > (MPC823)
> >
> >>>project to GCC 3.2 with EABI fully implemented but never tried to embed
> >>
> > C++.
> >
> >>>
> >>>
> >>>You wouldn't believe the time I spent searching my source codes for why
> >>>
> >>>__main() was not called (yes, I can be thick at times :-). Though I've
> >>>understood
> >>>
> >>>your explanation (and GREATLY appreciate it - thanks), I would like to
> >>
> > find
> >
> >>>further details of exactly what code is automatically or manually placed
> >>
> > in
> >
> >>>'.init' and '.fini' sections. Thanks again.
> >>>
> >>>
> >>>
> >>>Gary R. Garrison
> >>>
> >>
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> ------------------------------------------------------------------------
> >> [Date Prev
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00235.html>][Date
> >> Next
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00237.html>][Thread
> >> Prev
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00069.html>][Thread
> >> Next
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00247.html>][Date
> >> Index
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/date4.html#00236>][Thread
> >> Index
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/thrd2.html#00236>]
> >>
> >>
> >>
> >> Re: C++ static constructor problem
> >>
> >> ------------------------------------------------------------------------
> >>
> >> * /Date/: Mon, 25 Nov 2002 20:44:31 -0800
> >> * /From/: Till Straumann <strauman at SLAC.Stanford.EDU
> >> <mailto:strauman at SLAC.Stanford.EDU>>
> >> * /Subject/: Re: C++ static constructor problem
> >>
> >> ------------------------------------------------------------------------
> >>
> >>Hi all.
> >>
> >>Hadn't come across this since I only had dynamically loaded C++
> >>modules recently.
> >>
> >>I can reproduce Kate's problem. A simple test example (see below)
> >>works fine when built with gcc-2.95.3 but fails when built with gcc3.2
> >>(OAR RPM for linux, vers. gcc3.2newlib1.10.0-2).
> >>
> >>2 hours of research revealed some sort of mess between how different
> >>versions of gcc and rtems and CPUs perform constructor calls:
> >>
> >>NOTE: I am NOT a gcc internals expert
> >>
> >>A) GCC
> >> 1) older gcc versions (2.95.3) uses two flavors:
> >> i) systems who support '.init'/'.fini' sections are expected
> >> to use 'crtbegin/crtend'; crtbegin/crtend embed
> >> __do_global_ctors() into the '.init' section
> >> ii) for other systems, __do_global_ctors is built into __main()
> >>
> >> Although powerpc-eabi falls under i), it is treated as ii) with
> >> __main() redefined to __eabi(); __eabi() calls
> >> __do_global_ctors() (also defined by eabi code).
> >>
> >> 2) newer gcc versions (3.2) behaves different:
> >> a) powerpc-eabi defines __main() to __eabi() which is still
> >> called by main().
> >> b) __eabi() does NOT define nor call __do_global_ctors()
> >> but calls __init() instead.
> >> c) __init() executes the list of function pointers embedded
> >> into the '.init' section.
> >> d) Correct behavior could probably be obtained by using
> >> 'crtbegin/crtend' (spec file mod.) - this would result in
> >> constructor calls ending up in '.init', hence they would
> >> be executed under c) -- see B however.
> >>
> >>B) RTEMS
> >> 1) rtems may call __main or __init on its own (__USE_MAIN__,
> >> __USE_INIT_FINI__, respectively). Most BSPs have __USE_INIT_FINI__
> >> defined, i.e. the list in '.init' is actually executed TWICE :-O
> >> Once by main()-->__eabi()-->__init() and one more time by
> >> RTEMS (score/src/threadhandler.c)
> >>
> >>Summary GCC 3.2/RTEMS behavior (built with __USE_INIT_FINI__):
> >> x) app defines main(), crtbegin/crtend _not_ used:
> >> C++ constructors are _not_ executed (but other stuff in
> >> '.init' is executed twice.
> >> y) app defines main(), crtbegin/crtend _are_ used:
> >> C++ constructors are executed twice.
> >> z) app does not define main(), crtbegin/crtend _are_ used:
> >> C++ constructors are executed once
> >>
> >>NOTES:
> >> 1) Solution z) might be OK, including eh frame registration
> >> 2) ctors/dtors are not the only C++ issue. If those are called
> >> by any other means but __init(), eh frame registration must
> >> also be taken care of.
> >> 3) Cexp, when used on a system with statically linked C++ code,
> >> might be unable to collapse '.gnu.linkonce.xxx' sections into
> >> the statically linked part
> >> because these sections are flattened out into the .text/.data
> >> sections by the static link (unless preserved by the linker script).
> >>
> >>Sorry for the long message - as I said, I'm not GCC expert and
> >>the analysis might miss some details.
> >>
> >>As can be seen one more time: C++ is the DEVIL lurking in the details.
> >>
> >>-- Till
> >>
> >>APPENDIX: test example code
> >>
> >>init.c:
> >>
> >> /* configuration macros/includes go here */
> >>
> >> int
> >> main(int argc, char **argv){ return 0;}
> >>
> >> rtems_task
> >> Init(void *unused) { main(0,0); }
> >>
> >>tst.cc:
> >> #include <stdio.h>
> >> int i=printf("hello\n");)
> >>
> >>
> >>Kate Feng wrote:
> >>> Hi Joel,
> >>>
> >>> I tried to post the following message to the rtems-users mailing list
> >>> last week. However, it did not succeed. Why does this happen ?
> >>> Could you please help me to post it ?
> >>>
> >>> The platform :
> >>> gcc-3.2 cross compiler,
> >>> RTEMS version : rtems-ss-20021007
> >>> taget BSP : MVME2307
> >>>
> >>> Problem :
> >>>
> >>> In my application, there are some C++ static constructors which are
> >>> supposed to run on application startup. However, it did not happen at
> >>> all. It seems that __do_global_ctors was not in the gcc library.
> >>> My question is that is the C++ static constructors implemented
> >>> in the gcc-3.2 cross compiler for powerpc or maybe it is just my local
> >>> building error ?
> >>>
> >>>
> >>> I thought the C++ static constructor was built in the gcc-3.2 crosss
> >>> compiler.
> >>> However, the __do_global_ctors is missing.
> >>> I thought maybe I can start to modify the gcc-3.2/gcc/libgcc2.c
> >>> file or the crtstuff.c file. However, everything else in my current
> >>> platform
> >>> works fine. I do not want to make it worse if it was already
> >>> supported.
> >>> Any pointer would be highly appreciated.
> >>>
> >>>
> >>>
> >>> Thanks in advance,
> >>> Kate
> >>>
> >>> S. Kate Feng
> >>> Brookhaven National Lab.
> >>> National Synchrotron Light Source
> >>> Bldg. 725D
> >>> Upton, New York 11973-5000
> >>>
> >>> Email: feng1 at bnl.gov
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> * *Follow-Ups*:
> >> o *Re: C++ static constructor problem
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00247.html>*
> >>
> >> + /From:/ gregory.menke at gsfc.nasa.gov
> >>
> >> * Prev by Date: *Re: RTEMS networking (RTL 8139)
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00235.html>*
> >>
> >> * Next by Date: *Re: RTEMS networking (RTL 8139)
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00237.html>*
> >>
> >> * Previous by thread: *Re: building problems
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00069.html>*
> >>
> >> * Next by thread: *Re: C++ static constructor problem
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/msg00247.html>*
> >>
> >> * Index(es):
> >> o *Date*
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/date4.html#00236>
> >>
> >> o *Thread*
> >> <http://www.rtems.com/rtems/maillistArchives/rtems-users/2002/november/thrd2.html#00236>
> >
> >
--
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
More information about the users
mailing list