Undefined weak symbol bug

H. J. Lu hjl@lucon.org
Mon Mar 31 19:01:00 GMT 2003


On Fri, Mar 28, 2003 at 07:32:11PM -0800, Roland McGrath wrote:
> I am not convinced there is any dynamic linker bug here.  There are
> definitely ld bugs.  I don't see what would still be wrong if those were
> fixed, however.  Because of the hidden visiblity, both symbols ought to
> have been resolved to zero at link time.  
> 
> The "main_hidden" case shows an ld bug in producing a local .bss value in
> the executable as if for a copy reloc.  The R_386_NONE reloc generated is
> probably the remnant of the R_386_COPY it thought it was going to produce.
> 
> The "shared_hidden" case shows an ld bug in producing a .dynsym entry at all
> rather than resolving it to zero at link time.

There is no doubt that ld doesn't handle weak, undefined symbols
with non-default visibility right. But it is not very clearly to
me how ld should handle it. The gABI says

First, all of the non-default visibility attributes, when applied
to a symbol reference, imply that a definition to satisfy that
reference must be provided within the current executable or shared
object. If such a symbol reference has no definition within the
component being linked, then the reference must have STB_WEAK
binding and is resolved to zero.

Should ld or ld.so resolve it to zero? If ld does, should the
binding be changed to STB_LOCAL and remove the relocation entry?


H.J.



More information about the Binutils mailing list