Re: PATCH: Fix gold problem with weak undefined symbols

[Ian Lance Taylor <iant at google dot com>]

Alan Modra <amodra@bigpond.net.au> writes:

> On Tue, Apr 01, 2008 at 08:18:52PM -0400, Daniel Jacobowitz wrote:
>> On Tue, Apr 01, 2008 at 05:13:06PM -0700, Cary Coutant wrote:
>> > Yep, that appears to be what GNU ld does -- the test case passes for
>> > GNU ld, and I see no dynamic relocation for the weak undef symbol. It
>> > was surprising to me, too, which is why gold didn't do this
>> > originally.
>> 
>> I think I recall a conversation between Alan and H.J. a month or two
>> ago, in which this was classified as a bug.  Might want to ask them.
>
> See http://sourceware.org/ml/binutils/2008-02/msg00264.html for my
> argument as to why we ought to emit dynamic relocs for undefined weak
> symbols.

It's a logical argument.  However, on the x86-64, using the (default)
small model, if we compile code like this in non-PIC mode:

extern char foo[] __attribute__((weak));
char* fooval() { if (foo) return foo; else return 0; }

we get a R_X86_64_32S relocation for the second reference to foo from
fooval.  If we then link this code into an executable linked against a
shared library which does not define foo, then as I understand it your
argument is that we should emit a dynamic relocation for the reference
to foo in fooval.  This dynamic relocation will have to have type
R_X86_64_32_S.  However, the x86-64 dynamic linker does not support
that relocation type.  It does not support that relocation type
because it is in general unsatisfiable: the symbol may be defined by a
shared library which may be loaded anywhere in the 64-bit address
space, and thus may not be in range for a 32-bit signed offset.

Even if we argue that that is a bug, and that we should change glibc
to resolve these relocations when possible, and that we should change
the GNU linker to emit these dynamic relocations, we have to deal with
today's reality: if we emit those dynamic relocs today, an executable
built from the above code will not run on x86-64, because the dynamic
linker will give an error about an unexpected reloc type.

Suggestions?

Ian