This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Make global file function names link unique
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: geoffk at apple dot com (Geoffrey Keating)
- Cc: gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com
- Date: Mon, 18 Dec 2006 19:57:30 -0500 (EST)
- Subject: Re: [PATCH] Make global file function names link unique
> The property of first_global_object_name is that
> first_global_object_name is set to this value only for this
> compilation in the whole link. If this is not happening on HP-UX, it
> would be better to fix that rather than work around it. For example,
> in the first patch you quoted, this happens "because ... overrides
> new", so perhaps an override of new should not be placed in
> first_global_object_name (although I do not see why this causes a
> problem; there can be only one override of new in a whole program).
> This is the only purpose of first_global_object_name, so if this can
> not be made to work then first_global_object_name is useless and
> should be removed.
first_global_object_name is not being set to a value that's unique
for all links with libstdc++. first_global_object_name is the same
for an object in libstdc++.sl and for the object with the overloaded
value of new in the cxa_vec application. As a result, the initializer
for the EH unwind data in libstdc++ doesn't run and the unwind data
for libstdc++ doesn't get properly initialized. Obviously, if this
can happen with libstdc++ it can happen with other shared libraries.
The reason this isn't more common is that most targets don't use
'F'. They place the frame data in .eh_frame instead of in the data
section. As a result, they don't need a global function to initialize
the frame data.
You might ask why the frame data needs to be initialized for a function
that has been overloaded. The answer is the FDE search for libstdc++ breaks
when the initializer isn't run. The exception search algorithm depends
on the correct ordering of FDEs and the 'F' initializers need to run.
I haven't investigated PR 30151 in any great detail but it's clear
we have duplicate constructor/destructor names for an object in
libtestc++.a and in the test object. The tests that fail with this
error aren't new and never failed before. If both objects are needed,
there's a problem.
The 32-bit HP-UX targets use collect2 to setup constructors/destructors.
Thus, HP-UX is sensitive to conflicts in global initializers. Most
targets are using .init/.fini or .init_array/.fini_array to run
constructors/destructors. Thus, they don't see the effect of your
change with respect to 'I' and 'D'.
first_global_object_name does provide a name that's unique to a
compilation unit. This does provide a quick and easy method to
provide 'I' and 'D' names when these names are local. The situation
is not so clear when these names have to be global. If the functions
have to be called when the names are overloaded, then we need to
try harder to provide file function names that always will be called.
J. David Anglin firstname.lastname@example.org
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)