From patchwork Wed Mar 19 20:11:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella X-Patchwork-Id: 331867 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id D4EAC2C00B9 for ; Thu, 20 Mar 2014 07:11:45 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=default; b=bxhx27es9Lbe3dC+o9DB2N0EHXit+39oy3SskF1bRvi ZuuarW+1H2ZcMJT5FzlThaRvw0xyXHI55srQr0wpF/4Dh/wLGX1cX46lK1oymLwO CN6NJbpTSwB3Y5pP5AIgFZL93iVlrIB9PzNELm/LJF0oyvzGzHEwoRmOWIylqvIo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:message-id:date:from:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; s=default; bh=lTRAbsPQDff7RrSIFWKLZLrmMPg=; b=KXBgAcvCm2bJTOXGG IzH2DT+hS2mytP7LyxcbqOA4DjP6+CMjM4DOlY/AMOXuaGNHiub/uYpa4A2d38Vo RNp8F3HizpWLh+LrnFssODIYuwc4fD6vtbxaEBz/6YwHefn0pNjKmAh47hd+WxeR joaTRr0oLKFuELBSFVecPwke0M= Received: (qmail 9598 invoked by alias); 19 Mar 2014 20:11:40 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 9589 invoked by uid 89); 19 Mar 2014 20:11:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e24smtp01.br.ibm.com Message-ID: <5329F9F2.6060900@linux.vnet.ibm.com> Date: Wed, 19 Mar 2014 17:11:30 -0300 From: Adhemerval Zanella User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: libc-alpha@sourceware.org Subject: Re: [PATCH] Fix localplt check for GNU_IFUNC References: <531B63DE.5090803@linux.vnet.ibm.com> <5329E65A.5010703@redhat.com> In-Reply-To: <5329E65A.5010703@redhat.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14031920-1524-0000-0000-00000940F02A On 19-03-2014 15:47, Carlos O'Donell wrote: > On 03/08/2014 01:39 PM, Adhemerval Zanella wrote: >> While reviewing the strncat optimization for powerpc64 I noted in the >> disassembled object that a call to strlen (bl strlen) generates a PLT >> call to strlen (since now strlen is an IFUNC for powerpc64). Strangely >> it was not being caught by check-localplt testcase. >> >> GNU_IFUNC are shown by readelf in 'Relocation section' value as (symbol) >> instead of expected hexadecimal value. This causes the check-localplt >> script to igore potential PLT stub begin generated by wrong IFUNC usage. >> This patch changes the localplt script to emit such PLT cases. >> >> Checked on PPC64 and X86_64. >> >> -- >> >> 2014-03-03 Adhemerval Zanella >> >> * scripts/localplt.awk: Do not ignore IFUNC relocation while parsing >> relocation sections. > Can you show example output? > > On x86-64 I see: > 0000003000bba030 0000034400000007 R_X86_64_JUMP_SLOT memset() memset + 0 > 0000003000bba048 000007ba00000007 R_X86_64_JUMP_SLOT memmove() memmove + 0 > > Not (memset) or (memmove). > > I'd like to see this fixed... and this is the first patch in patchtracker :-) Thanks for the review Carlos. I rechecked the patch here and I did some confusion (although the patch itself was not really incorrect). Indeed from binutils/readelf.c:1315 comment: 1315 /* Relocations against GNU_IFUNC symbols do not use the value 1316 of the symbol as the address to relocate against. Instead 1317 they invoke the function named by the symbol and use its 1318 result as the address for relocation. 1319 1320 To indicate this to the user, do not display the value of 1321 the symbol in the "Symbols's Value" field. Instead show 1322 its name followed by () as a hint that the symbol is 1323 invoked. */ And by changing the strncat.S powerpc implementation to call the ifunc directly: diff --git a/sysdeps/powerpc/powerpc64/power7/strncat.S b/sysdeps/powerpc/powerpc64/power7/strncat.S index 1a1a95e..23861f6 100644 --- a/sysdeps/powerpc/powerpc64/power7/strncat.S +++ b/sysdeps/powerpc/powerpc64/power7/strncat.S @@ -69,7 +69,7 @@ EALIGN(STRNCAT, 4, 0) beq cr0,L(done) mr r31, r4 /* Save "s2" in r31 from r4. */ - bl STRLEN /* Call optimized strlen on s1; goto + bl strlen /* Call optimized strlen on s1; goto end of s1. */ nop cmpldi cr7, r29, 7 /* If s2 is <=7 process And rebuilding it I see: $ LC_ALL=C readelf -W -S -d -r libc.so | grep strlen 00000000001f2bc8 0000033b00000015 R_PPC64_JMP_SLOT strlen() strlen + 0 So below there is a slight modified patch to address it (I didn't add the ChangeLog). What do you think ? --- diff --git a/scripts/localplt.awk b/scripts/localplt.awk index 2265b02..f55c41a 100644 --- a/scripts/localplt.awk +++ b/scripts/localplt.awk @@ -32,9 +32,15 @@ $1 == "Offset" && $2 == "Info" { in_relocs = 1; next } NF == 0 { in_relocs = 0 } in_relocs && relocs_offset == jmprel_offset && NF >= 5 { - symval = strtonum("0x" $4); - if (symval != 0) + # Relocations against GNU_IFUNC symbols are not shown as an hexadecimal + # value, but rather as the resolver symbol followed by (). + if ($4 ~ /\(\)/) { print whatfile, $5 + } else { + symval = strtonum("0x" $4); + if (symval != 0) + print whatfile, $5 + } } in_relocs { next }