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