This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A symbol visibility problem

On Wed, Jan 28, 2004 at 11:32:42AM +0000, Nick Clifton wrote:
> Hi H. J. Lu" <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]