This is the mail archive of the mailing list for the glibc 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: 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 resolve it to zero? If ld does, should the
binding be changed to STB_LOCAL and remove the relocation entry?


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