public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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 --]

  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).