Re: Bug#62008: ld leaves hidden/internal symbols in the symbol table (Patch Included)

[Martin von Loewis <loewis at informatik dot hu-berlin dot de>]

> > > >       /* XXX: The ABI draft says the linker must turn hidden and
> > > >          internal symbols into STB_LOCAL symbols when producing the
> > > >          DSO. However, if ld.so honors st_other in the dynamic table,
> > > >          this would not be necessary.  */
> > 
> > No!!!  This is wrong!  .hidden and .protected must jump through the
> > PLT.  This is part of the whole plan.  If it does not work with the
> > current ld.so.: too bad.  This is brand new functionality.  Wait for
> > glibc 2.2 or appropriately changed loaders on other architectures.

I'm not sure what "this" refers to in this context. The ABI spec says,
in "ch4.symtab.html", which H.J. just sent me (right in the STV_HIDDEN
bullet item)

# A hidden symbol contained in a relocatable object must be either
# removed or converted to STB_LOCAL binding by the link-editor when
# the relocatable object is included in an executable file or shared
# object.

That seems pretty clear to me. Removing the symbol is sometimes not
possible, because it has to go through the PLT. It still could be
STB_LOCAL - even though that would violate the requirement that all
dynamic symbols should be global. 

Personally, I don't care whether the symbol is local or global. It
must be in the PLT, that is true. However, I'd prefer that binutils
implement the ABI, even if it is counter-intuitive. So if you present
me an ABI draft which has that requirement removed, I happily update
my patch.

> I'd like to fix it in binutils 2.10. Or we should back all of them
> out.

Please read the ABI spec carefully. I believe my patch implements it
correctly, and I also believe ld.so *could* process the symbols
properly. For example, in glibc's do-lookup, STB_LOCAL symbols should
be accepted if they are STV_HIDDEN, and if they originate from the
same DSO.

I agree there is some conflict here, and it needs to be
resolved. However, fixing binutils to match glibc won't buy you
anything - dynamic linkers of other systems still may comply with the
spec, and thus fail to work with binutils.

Regards,
Martin