Re: A glibc dynamic linker or gld bug?

[Ian Lance Taylor <ian@zembu.com>]

   Date: Thu, 8 Jul 1999 13:12:03 +1000
   From: Geoff Keating <geoffk@ozemail.com.au>

   >    These cases are not fixable under the usual non-pic-executable model, in
   >    which all addresses referenced by the executable are fixed at link
   >    time.
   > 
   > No, they are fixable.  We just need to generate the appropriate
   > dynamic relocations.  At present we do not do that, but there is
   > nothing preventing us from doing it.

   To be precise:

   These cases, if fixed by outputting all relevant relocations, would
   lead to incredibly inefficient program loading because it would be
   necessary to have run-time relocs for any weak symbol referenced by the
   executable.  It would also cost large amounts of memory because the
   text segment of executables would no longer be sharable between
   invocations.

Does the average executable really reference that many weak symbols?

   For instance, consider the following tiny bit of code, which we assume
   goes in an executable:

   extern int foo(void);
   int main(void) { if (foo) return foo(); else return 42; }

I can only follow your example if I assume that foo is weak undefined
in the executable, although that does not appear above.

   Now, suppose foo() goes away in a future version of the DSO.  Now we
   have a weak symbol which isn't defined anywhere, so it has address 0.

If foo is not weak undefined in the executable, then if it goes away
in the DSO, the dynamic linker will signal an error at run time.  It
doesn't matter that the foo is weak defined in the DSO.  If the
executable has a non-weak reference which can not be satisfied, the
program can not be run.

   This will happen a lot.  For instance, in current glibc 'open()' is
   weak.  open() is not likely to go away, but the linker doesn't know
   that.

The fact that open is weak defined in libc.so does not imply that it
is weak undefined in the executable.

I completely agree that to fix the various cases in your original note
we must issue dynamic relocations for all weak symbols, both defined
and undefined, in the executable.  However, we do not have to issue
relocations for symbols merely because they happen to be weak in a
shared object.

The average executable probably doesn't refer to any weak symbols in
user written code.  On the crt*.o files on my RedHat 5.2 system, the
weak symbol data_start is defined and the weak symbol __gmon_start__
is referenced.  The relocations for __gmon_start__ are GOT and PLT
relocs, and as such should not require any modification to the text
section at run time.

I do agree that making this work reliably would have a cost.  But I'm
not sure the cost would be as high as you suggest it would be.

Ian