From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27877 invoked by alias); 26 Nov 2009 03:11:50 -0000 Received: (qmail 27863 invoked by uid 22791); 26 Nov 2009 03:11:48 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,HK_OBFDOM,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Nov 2009 03:11:44 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAQ3Bgbx027560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2009 22:11:42 -0500 Received: from stone.twiddle.home (vpn-243-185.phx2.redhat.com [10.3.243.185]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAQ3BfMn030112; Wed, 25 Nov 2009 22:11:42 -0500 Message-ID: <4B0DF1EC.30001@redhat.com> Date: Thu, 26 Nov 2009 03:11:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: yunfeng zhang CC: gcc@gcc.gnu.org, Andrew Haley Subject: Re: No .got section in ELF References: <4df04b840911231758md5a545el2d417b663af1647f@mail.gmail.com> <4df04b840911251824j71fa1d33i2cecc9481617dda5@mail.gmail.com> In-Reply-To: <4df04b840911251824j71fa1d33i2cecc9481617dda5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00739.txt.bz2 On 11/25/2009 06:24 PM, yunfeng zhang wrote: > It seems that original limitation isn't clear or sufficient > > For a sample: > > // f.c > int g; > void foo(void) > { > g = 1; > } > > compile with `gcc -shared -fPIC -Wl,-soname,f.so,-Map,f.map -o f.so f.c'... With -fPIC, the variable G may be overridden by another variable of the same name from another shared object earlier in the search path. That is, the offset is *not* fixed because the final address of G may reside in a different .so file. Change your program to static int g; or extern int g __attribute__((visibility("hidden"))); int g; and compare the results. In either case G is known to resolve to the instance present in f.so. In either case we'll use a constant offset. You really need to understand how ELF actually works before suggesting that it's broken. r~