From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14263 invoked by alias); 13 Jun 2009 06:01:24 -0000 Received: (qmail 14173 invoked by uid 22791); 13 Jun 2009 06:01:24 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_22,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Jun 2009 06:01:17 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n5D61FlS032764; Sat, 13 Jun 2009 02:01:15 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5D61FJg019186; Sat, 13 Jun 2009 02:01:15 -0400 Received: from [192.168.7.77] (vpn-12-52.rdu.redhat.com [10.11.12.52]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5D61C0Z014115; Sat, 13 Jun 2009 02:01:12 -0400 Message-ID: <4A3340A6.8020107@redhat.com> Date: Sat, 13 Jun 2009 06:01:00 -0000 From: Ulrich Drepper User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jakub Jelinek CC: "H.J. Lu" , Glibc hackers , binutils@sources.redhat.com Subject: Re: Preliminary prelink IFUNC support (x86-64 only so far), some binutils IFUNC issues References: <20090612160251.GJ3101@sunsite.ms.mff.cuni.cz> In-Reply-To: <20090612160251.GJ3101@sunsite.ms.mff.cuni.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00001.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakub Jelinek wrote: > On the attached ifunctest.c gcc -O2 -o ifunctest{,.c} compiles/links, but > no R_*_IRELATIVE relocation is emitted and not surprisingly it crashes > at runtime. Prelink testsuite contains similar testcase, just using > .globl or .globl/.hidden, instead of .local. I'd say .local @gnu_indirect_function > symbols should be supported as well. Indeed, there is no reason why .local symbols shouldn't be supported. > The other issue can be seen with: > gcc -O2 -fpic -shared -o ifunc3lib1.{so,c} > gcc -O2 -o ifunc3 ./ifunc3lib1.so > ./ifunc3lib1 > Here, &lib1t3 in the binary resolves to a .plt slot in the binary, while > &lib1t3 in the shared library resolves to the actual address the ifunc > returned. > Not sure what exactly we want to do here, but the function pointers should > be the same. It's tricky alright. There really isn't a good answer for this. The existing behavior is the only sensible solution. One could try to make things more complicated by changing the linker to associate the symbol with the PLT slot and somehow allow ld.so to recognize such symbols, but I think it's not worth it. This all comes about only because IFUNCs are used in situations where they really were not meant to be used. IFUNC are supposed to be definitions in DSOs which can be used in place of FUNC symbols. This will work without changes to any semantics. In your test case you're creating and IFUNC symbol in the executable. While I have no problem with supporting it this does mean the program author take responsibility for doing this. I think we can in this case very well live with the difference in function addresses. Therefore I suggest to leave this case and just document it. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkozQKYACgkQ2ijCOnn/RHS7ggCeIAD4keHAfellDswGieDBNSAX /AgAoJKzcpoIcLyY25cJAfJ3FirrDd9k =77gy -----END PGP SIGNATURE-----