From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3377 invoked by alias); 24 May 2006 13:21:17 -0000 Received: (qmail 3325 invoked by uid 22791); 24 May 2006 13:21:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.31) with SMTP; Wed, 24 May 2006 13:20:40 +0000 Received: (qmail invoked by alias); 24 May 2006 13:16:44 -0000 Received: from host-6.mikroweb.hu (EHLO mail.bridge.intra) [193.17.175.6] by mail.gmx.net (mp030) with SMTP; 24 May 2006 15:16:44 +0200 X-Authenticated: #507653 Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EBFA9BA71; Wed, 24 May 2006 15:16:40 +0200 (CEST) Received: from mail.bridge.intra ([127.0.0.1]) by localhost (lnx.bridge.intra [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22412-04; Wed, 24 May 2006 15:16:27 +0200 (CEST) Received: by mail.bridge.intra (Postfix, from userid 200) id 44487BA76; Wed, 24 May 2006 15:16:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.bridge.intra (Postfix) with ESMTP id 1086FBA71; Wed, 24 May 2006 15:16:26 +0200 (CEST) Date: Wed, 24 May 2006 15:06:00 -0000 From: "Peter S. Mazinger" To: Alan Modra cc: "Peter S. Mazinger" , Subject: Re: weak and strong aliases for global data fail In-Reply-To: <20060523052712.GC12196@bubble.grove.modra.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Y-GMX-Trusted: 0 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00434.txt.bz2 On Tue, 23 May 2006, Alan Modra wrote: > 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. The app is a simplified version of getopt() used in glibc, but it happens with getopt.c from glibc as well. I have only renamed the internally used opt* to __opt* and provided a weak resp. strong alias to the externally visible version (also renamed to opt*_test so that it does not conflict with the libc provided getopt interface). Peter -- Peter S. Mazinger ID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2