From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114437 invoked by alias); 25 Mar 2018 19:33:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114383 invoked by uid 89); 25 Mar 2018 19:33:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 25 Mar 2018 19:33:13 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C1FA401CC41; Sun, 25 Mar 2018 19:33:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75464202699A; Sun, 25 Mar 2018 19:33:11 +0000 (UTC) Subject: Re: [PATCH v2 13/15] PPC64: always make synthetic .text symbols for GNU ifunc symbols To: gdb-patches@sourceware.org References: <20180325191943.8246-1-palves@redhat.com> <20180325191943.8246-14-palves@redhat.com> Cc: Binutils From: Pedro Alves Message-ID: <6844045b-c400-ea4e-430e-37fe7973ebcf@redhat.com> Date: Sun, 25 Mar 2018 19:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180325191943.8246-14-palves@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-03/txt/msg00520.txt.bz2 Dear binutils friends, This is a bfd patch that is part of a larger gdb patch series, whose cover letter is found here: https://sourceware.org/ml/gdb-patches/2018-03/msg00504.html Thanks, Pedro Alves On 03/25/2018 08:19 PM, Pedro Alves wrote: > If you create an ifunc using GCC's __attribute__ ifunc, like: > > extern int gnu_ifunc (int arg); > static int gnu_ifunc_target (int arg) { return 0; } > __typeof (gnu_ifunc) *gnu_ifunc_resolver (unsigned long hwcap) { return gnu_ifunc_target; } > __typeof (gnu_ifunc) gnu_ifunc __attribute__ ((ifunc ("gnu_ifunc_resolver"))); > > then you end up with two (function descriptor) symbols, one for the > ifunc itself, and another for the resolver: > > (...) > 12: 0000000000020060 104 FUNC GLOBAL DEFAULT 18 gnu_ifunc_resolver > (...) > 16: 0000000000020060 104 GNU_IFUNC GLOBAL DEFAULT 18 gnu_ifunc > (...) > > Both ifunc and resolver symbols have the same address/value, so > ppc64_elf_get_synthetic_symtab only creates a synthetic text symbol > for one of them. In the case above, it ends up being created for the > resolver, only: > > (gdb) maint print msymbols > (...) > [ 7] t 0x980 .frame_dummy section .text > [ 8] T 0x9e4 .gnu_ifunc_resolver section .text > [ 9] T 0xa58 __glink_PLTresolve section .text > (...) > > GDB needs to know when a program stepped into an ifunc resolver, so > that it can know whether to step past the resolver into the target > function without the user noticing. The way GDB does it is my > checking whether the current PC points to an ifunc symbol (since > resolver and ifunc have the same address by design). > > The problem is then that ppc64_elf_get_synthetic_symtab never creates > the synchetic symbol for the ifunc, so GDB stops stepping at the > resolver (in a test added by the following patch): > > (gdb) step > gnu_ifunc_resolver (hwcap=21) at gdb/testsuite/gdb.base/gnu-ifunc-lib.c:33 > 33 { > (gdb) FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=1: final_debug=0: step > > After this commit, we get: > > [ 8] i 0x9e4 .gnu_ifunc section .text > [ 9] T 0x9e4 .gnu_ifunc_resolver section .text > > And stepping an ifunc call takes to the final function: > (gdb) step > 0x00000000100009e8 in .final () > (gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=1: final_debug=0: step > > An alternative to touching bfd I considered was for GDB to check > whether there's an ifunc data symbol / function descriptor that points > to the current PC, whenever the program stops, but discarded it > because we'd have to do a linear scan over .opd over an over to find a > matching function descriptor for the current PC. At that point I > considered caching that info, but quickly dismissed it as then that > has no advantage (memory or performance) over just creating the > synthetic ifunc text symbol in the first place. > > I ran the binutils and ld testsuites on PPC64 ELFv1 (machine gcc110 on > the GCC compile farm), and saw no regressions. This commit is part of > a GDB patch series that includes GDB tests that fail without this fix. > > OK to apply? > > bfd/ChangeLog: > yyyy-mm-dd Pedro Alves > > * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Don't consider > ifunc and non-ifunc symbols duplicates. > --- > bfd/elf64-ppc.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/bfd/elf64-ppc.c b/bfd/elf64-ppc.c > index 751ad778b26..791ec49b73d 100644 > --- a/bfd/elf64-ppc.c > +++ b/bfd/elf64-ppc.c > @@ -3330,13 +3330,23 @@ ppc64_elf_get_synthetic_symtab (bfd *abfd, > > if (!relocatable && symcount > 1) > { > - /* Trim duplicate syms, since we may have merged the normal and > - dynamic symbols. Actually, we only care about syms that have > - different values, so trim any with the same value. */ > + /* Trim duplicate syms, since we may have merged the normal > + and dynamic symbols. Actually, we only care about syms > + that have different values, so trim any with the same > + value. Don't consider ifunc and ifunc resolver symbols > + duplicates however, because GDB wants to know whether a > + text symbol is an ifunc resolver. */ > for (i = 1, j = 1; i < symcount; ++i) > - if (syms[i - 1]->value + syms[i - 1]->section->vma > - != syms[i]->value + syms[i]->section->vma) > - syms[j++] = syms[i]; > + { > + const asymbol *s0 = syms[i - 1]; > + const asymbol *s1 = syms[i]; > + > + if ((s0->value + s0->section->vma > + != s1->value + s1->section->vma) > + || ((s0->flags & BSF_GNU_INDIRECT_FUNCTION) > + != (s1->flags & BSF_GNU_INDIRECT_FUNCTION))) > + syms[j++] = syms[i]; > + } > symcount = j; > } > >