public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: "Peter S. Mazinger" <ps.m@gmx.net>
Cc: binutils@sourceware.org
Subject: Re: weak and strong aliases for global data fail
Date: Tue, 23 May 2006 09:35:00 -0000	[thread overview]
Message-ID: <20060523052712.GC12196@bubble.grove.modra.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0605222235570.10440-100000@lnx.bridge.intra>

On Mon, May 22, 2006 at 10:38:56PM +0200, Peter S. Mazinger wrote:
> On Wed, 17 May 2006, Peter S. Mazinger wrote:
> 
> Could anyone tell me if this is a binutils bug (tested 2.16.1/2.16.92) or 
> I should send it to the gcc list (tested with 3.4.6). It seems to me that 
> it is rather an ld bug.
> 
> Thanks, Peter
> 
> > Hello!
> > 
> > Attached tests show a case, when a final binary is OK if 
> > compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be), 
> > else it fails if using aliases (both weak and strong) for global data.
> > 
> > Sorry for the "big" test cases, I couldn't make them smaller.

It's a user bug.  When the linker needs to generate a copy reloc, eg. as
it does for x86 non-PIC code, for a variable like "optind_test" in your
main app, then space is allocated in your main app and initialised from
the shared object.  The main app uses this location for references to
"optind_test", as do references from within the shared lib.  However,
your shared lib is not referencing "optind_test" but an alias stored at
a different location (in the shared lib).

With PIC code the linker can generally dispense with the copy reloc, so
both the main app and the shared lib use the same location.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

  reply	other threads:[~2006-05-23  5:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 17:02 Peter S. Mazinger
2006-05-23  0:12 ` Peter S. Mazinger
2006-05-23  9:35   ` Alan Modra [this message]
2006-05-24 15:06     ` Peter S. Mazinger
2006-05-24 17:05       ` Alan Modra
2006-05-23 10:29 ` Mike Frysinger
2006-05-24 15:34   ` Peter S. Mazinger
2006-05-26  2:44     ` Mike Frysinger

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=20060523052712.GC12196@bubble.grove.modra.org \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sourceware.org \
    --cc=ps.m@gmx.net \
    /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).