------- Comment #5 from danglin at gcc dot gnu dot org 2007-10-28 15:28 -------
Changed my mind about my last comment. The new constructor priority
attribute breaks the previous C++ init_priority handling using collect2.
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.
However, sorting the calls in _GLOBAL__I_0_c1 and _GLOBAL__D_1_c1 isn't
going provide a consistent ordering across translation units. The previous
init_priority mechanism was more sophisticated.
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.
At the moment, I don't see any other viable mechanism. The HP linker
supports a SORT keyword on subspaces (sections) but it is only an eight
bit field and it looks like we need 16 bit priorities. We also don't
have the equivalent of crtbegin and crtend.
To fix initpri1.c, there would have to be a mechanism similar to the
old init_priority mechanism in GNU C++.
--
danglin at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33579
