This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Undefined weak symbol bug
- From: "H. J. Lu" <hjl at lucon dot org>
- To: Roland McGrath <roland at redhat dot com>
- Cc: GNU C Library <libc-alpha at sources dot redhat dot com>,binutils at sources dot redhat dot com
- Date: Mon, 31 Mar 2003 09:44:59 -0800
- Subject: Re: Undefined weak symbol bug
- References: <20030325160509.A25792@lucon.org> <200303290332.h2T3WBB30737@magilla.sf.frob.com>
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.