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

Joel Sherrill joel.sherrill at OARcorp.com
Wed Feb 12 17:40:27 UTC 2003



till wrote:
> 
> Joel Sherrill wrote:
> 
> >
> >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.
> >
> 
> Absolutely, it's just that _what_ it has to call is architecture (and
> probably compiler flag
> dependent). E.g. on one architecture, it may be fine to call __init().
> 
> On PPC however, I believe that '__eabi()' must be called _unless_
> -mno-eabi was specified
> which means that nothing should be done, AFAIK (i.e. the user takes care
> of initialization in
> some other way).

Which powerpc-* gcc target do you believe RTEMS is most similar to?
As pointed out in another thread, we do have prebuilt powerpc-eabi
to compare against.

> -- Till
> 
> >
> >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