This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Undefined weak symbol bug
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.