Re: [PATCH] Make global file function names link unique

[Geoffrey Keating <geoffk at apple dot com>]

On 18/12/2006, at 4:57 PM, John David Anglin wrote:

> > 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.

OK.  This should never happen.  To fix this bug, you should make it  
not happen.

As a first step, I would start by finding out what exactly this symbol  
is that's being used in first_global_object_name in two different  
objects.  Note that the standard operators 'new' in libstdc++ should  
be 'weak' or similar, and therefore should never appear in  
first_global_object_name.  It may be that there's something special  
about how it's handled in HP-UX which defeats this mechanism.

It is not obvious that it can happen with other shared libraries,  
since only libstdc++ defines weak versions of 'operator new'.

Attachment: smime.p7s
Description: S/MIME cryptographic signature