A symbol visibility problem

H. J. Lu hjl@lucon.org
Wed Jan 28 19:46:00 GMT 2004


On Wed, Jan 28, 2004 at 11:32:42AM +0000, Nick Clifton wrote:
> Hi H. J. Lu" <hjl@lucon.org> writes:
> 
> > The problem is
> >
> >       /* If the new symbol with non-default visibility comes from a
> >          relocatable file and the old definition comes from a dynamic
> >          object, we remove the old definition.  */
> >       if ((*sym_hash)->root.type == bfd_link_hash_indirect)
> >         h = *sym_hash;
> >       h->root.type = bfd_link_hash_new;
> >       h->root.u.undef.abfd = NULL;
> >  
> > If the new entry with non-default visibility is undefined, then
> > setting the type to bfd_link_hash_new will lead to the
> > assertion. Should we use
> >
> > 	h->root.type = bfd_link_hash_undefined;
> >
> > instead and let _bfd_generic_link_add_one_symbol take care of it?
> 
> That seems sensible, but I think only if the new symbol is undefined.
> 
> Do you have a patch to propose for this ?
> 

It is more complex than I thought. When we remove the old definition
coming from a DSO, we need to restore the previous state if the new
symbol is undefined. Set it to bfd_link_hash_undefined is wrong if
it was referenced before because the new symbol can be weak undefined,
which may lead to undefined symbol error. We can tell if it has been
referenced by checking h->root.und_next. The main problem is how to
maintain the linker hash table undefs list. If h->root.und_next is
not NULL, h may or may not be on the linker hash table undefs list.
We need to make sure it is on the linker hash table undefs list and
the undefs list won't be corrupted by it.


H.J.



More information about the Binutils mailing list