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

till strauman at slac.stanford.edu
Wed Feb 12 17:19:14 UTC 2003


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).

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






More information about the users mailing list