PATCH: Add _bfd_elf_provide_symbol

[Michael Matz]

Hi HJ,

On Mon, 25 Apr 2005, H. J. Lu wrote:

> > This patch introduces a regression for linking code with older glibcs on 
> > alpha, due to this error message:
> 
> Did you say it only happens with the older glibc?

Well, it's from last year:
% ll /usr/lib/libc_nonshared.a
-rw-r--r--  1 root root 50344 Apr 23  2004 /usr/lib/libc_nonshared.a
and is a 2.3.3 glibc.

so not that old.  The problem is the elf-init.oS member of that archive, 
which contains references to __fini_array_end and friends.  In current 
glibc CVS I still see the same references to those symbols in the source 
code (although it's obsolete one can't simply remove those functions, and 
anyway it would be too late for the above glibcs).  In particular we are 
talking about these relocations:

% objdump -r elf-init.oS | grep array
0000000000000008 GPRELHIGH         __fini_array_start
000000000000000c GPRELHIGH         __fini_array_end
0000000000000014 GPRELLOW          __fini_array_start
0000000000000018 GPRELLOW          __fini_array_end
00000000000000cc GPRELHIGH         __init_array_start
00000000000000d0 GPRELHIGH         __init_array_end
00000000000000d4 GPRELLOW          __init_array_start
00000000000000d8 GPRELLOW          __init_array_end

It should be noted that the alpha ld maps the executable start to beyond 
32 bit (as already mentioned in the last mail):
PROVIDE (__executable_start = 0x120000000); . = 0x120000000 + SIZEOF_HEADERS;

So, the difference between the symvalue 0 and GP is too large to fit into
signed 32 bit, which it must if GPRELHIGH/LOW relocations are used.

The libc_nonshared.a archive is linked into all executables so no 
executables can be produced anymore with the new binutils, as soon as they 
are installed one can't even build a new glibc (but I doubt this would 
change the error).  I had to hack the linker script to provide these 
symbols, and to make a gcc wrapper adding -Wl,-T,/elf-hack.x to link 
commands to be able to bootstrap this system again ;-)

> > I'm not 100% sure what the best alternative would be.  I think
> > simplest would be to define it to the start of .got, like in the below
> > patch.  It works for me on alpha, but I don't know if that's a sane
> > approach, or if .got is available everywhere (I guess with static
> > executables it's not).
> > 
> 
> Do you have a simple testcase for alpha which I can run on Linux/i386?

I've packed together the elf-init.oS file from the system, a small c file 
providing some symbols needed from that .oS, and this file precompiled for 
alpha.  So you should be able to reproduce the problem with:

% ld elf-init.oS a.o

with a cross linker.  This will of course not create a functioning 
executable, but will demonstrate the linking error.  With my patch this 
works.  Hope this helps.


Ciao,
Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hjtest.tar.gz
Type: application/x-gunzip
Size: 2222 bytes
Desc: 
URL: <https://sourceware.org/pipermail/binutils/attachments/20050425/bf541002/attachment.bin>