This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/33579] INIT_PRIORITY is broken
- From: "mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Oct 2007 22:46:47 -0000
- Subject: [Bug target/33579] INIT_PRIORITY is broken
- References: <bug-33579-276@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #6 from mark at codesourcery dot com 2007-10-28 22:46 -------
Subject: Re: INIT_PRIORITY is broken
danglin at gcc dot gnu dot org wrote:
> With respect to initpr1.c, it can be seen that only one "GLOBAL" constructor,
> _GLOBAL__I_0_c1, and one "GLOBAL" destructor, _GLOBAL__D_1_c1, are created.
> These respectively call all the constructors and destructors. The order of
> the calls is not sorted based on constructor priority, so the test fails.
I'm sorry to hear of this breakage.
> A global constructor visible to collect2 was output for each constructor/
> destructor priority (e.g., _GLOBAL__I$01000_foo). These would call
> a static function, _Z41__static_initialization_and_destruction_0ii, with
> two arguments, construct/destruct and priority. It would arrange to
> call the constructor/destructor for a given priority. Collect2 sorts
> the "GLOBAL" cdtors in terms of priority. The overall running of constructors
> and destructors is done using HP ld's +init and +fini arguments.
Right now, there are two primary cases for back ends: either they
support constructors and destructors (targetm.have_ctors_dtors is false,
and collect2's special handling is not required), or they don't
(targetm.have_ctors_dtors is false, and collect2 threads the _GLOBAL_*
functions together.)
I believe you're correct that my changes broke the handling of
prioritized constructors in the case where we use collect2. I didn't
realize that there were targets that did that before.
In order to fix this, I think the correct change would be to have
cgraphunit.c:cgraph_build_cdtor be smarter. In particular, it should
build one function for each priority, rather than building one function
for everything. Then, collect2 will work as before.
I don't think this will be too hard to implement. In
cgraph_build_cdtor_fns, we need to partition/sort the static_[cd]tors by
priority, and then pass each batch off to build_cdtor separately. Do
you want to work on this, or do you want me to do it?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33579