From: Michael Matz <matz@suse.de>
To: "H. J. Lu" <hjl@lucon.org>
Cc: binutils@sources.redhat.com
Subject: Re: PATCH: Add _bfd_elf_provide_symbol
Date: Mon, 25 Apr 2005 15:17:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.58.0504251703020.20714@wotan.suse.de> (raw)
In-Reply-To: <20050425145458.GA32362@lucon.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2799 bytes --]
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.
[-- Attachment #2: Type: APPLICATION/x-gunzip, Size: 2222 bytes --]
next prev parent reply other threads:[~2005-04-25 15:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-21 15:42 Yet another unnecessary powerpc section Alan Modra
2005-03-22 8:16 ` Alan Modra
2005-03-22 11:48 ` H. J. Lu
2005-03-22 12:06 ` Alan Modra
2005-03-22 17:37 ` PATCH: Add _bfd_elf_provide_symbol H. J. Lu
2005-03-23 4:19 ` H. J. Lu
2005-03-23 5:37 ` H. J. Lu
2005-03-23 9:28 ` Alan Modra
2005-03-23 9:31 ` Daniel Jacobowitz
2005-03-23 9:33 ` H. J. Lu
2005-04-25 4:53 ` Michael Matz
2005-04-25 14:55 ` H. J. Lu
2005-04-25 15:17 ` Michael Matz [this message]
2005-04-25 17:31 ` PATCH: Fix alpha relocation overflow (Re: PATCH: Add _bfd_elf_provide_symbol) H. J. Lu
2005-04-25 17:46 ` H. J. Lu
2005-04-26 12:01 ` Michael Matz
2005-04-26 13:47 ` H. J. Lu
2005-04-27 19:35 ` H. J. Lu
2005-05-03 1:27 ` Alan Modra
2005-05-03 1:35 ` H. J. Lu
2005-05-03 5:31 ` Alan Modra
2005-05-03 21:40 ` H. J. Lu
2005-05-04 6:18 ` Alan Modra
2005-05-04 6:50 ` H. J. Lu
2005-05-04 10:17 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0504251703020.20714@wotan.suse.de \
--to=matz@suse.de \
--cc=binutils@sources.redhat.com \
--cc=hjl@lucon.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).