More EABI/C++ issues (was Re: EABI and C++)
Till Straumann
strauman at SLAC.Stanford.EDU
Wed Feb 12 04:19:25 UTC 2003
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()).
- 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