From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108179 invoked by alias); 25 Mar 2018 19:29:01 -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 108168 invoked by uid 89); 25 Mar 2018 19:29:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_STOCKGEN,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:2283, secure 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:29:00 +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 2E7E5401CC41 for ; Sun, 25 Mar 2018 19:19:51 +0000 (UTC) Received: from localhost.localdomain (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id D4A0A202699A for ; Sun, 25 Mar 2018 19:19:50 +0000 (UTC) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH v2 10/15] For PPC64: elf_gnu_ifunc_record_cache: handle plt symbols in .text section Date: Sun, 25 Mar 2018 19:29:00 -0000 Message-Id: <20180325191943.8246-11-palves@redhat.com> In-Reply-To: <20180325191943.8246-1-palves@redhat.com> References: <20180325191943.8246-1-palves@redhat.com> X-SW-Source: 2018-03/txt/msg00517.txt.bz2 elf_gnu_ifunc_record_cache doesn't ever record anything on PPC64 (tested on gcc110 on the compile farm, CentOS 7.4, ELFv1), because that expects to find PLT symbols in the .plt section, while there we get: (gdb) info symbol 'gnu_ifunc@plt' gnu_ifunc@plt in section .text ^^^^^ I guess that may be related to the comment in ppc-linux-tdep.c that says "For secure PLT, stub is in .text". In any case, this commit fixes the issue by making the function look at the symbol name instead of at the section. gdb/ChangeLog: yyyy-mm-dd Pedro Alves * elfread.c (elf_gnu_ifunc_record_cache): Check if the symbol name ends in "@plt" instead of looking at the symbol's section. --- gdb/elfread.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/gdb/elfread.c b/gdb/elfread.c index 82ab3d891ce..4e79b080e65 100644 --- a/gdb/elfread.c +++ b/gdb/elfread.c @@ -687,7 +687,6 @@ static int elf_gnu_ifunc_record_cache (const char *name, CORE_ADDR addr) { struct bound_minimal_symbol msym; - asection *sect; struct objfile *objfile; htab_t htab; struct elf_gnu_ifunc_cache entry_local, *entry_p; @@ -698,14 +697,17 @@ elf_gnu_ifunc_record_cache (const char *name, CORE_ADDR addr) return 0; if (BMSYMBOL_VALUE_ADDRESS (msym) != addr) return 0; - /* minimal symbols have always SYMBOL_OBJ_SECTION non-NULL. */ - sect = MSYMBOL_OBJ_SECTION (msym.objfile, msym.minsym)->the_bfd_section; objfile = msym.objfile; /* If .plt jumps back to .plt the symbol is still deferred for later - resolution and it has no use for GDB. Besides ".text" this symbol can - reside also in ".opd" for ppc64 function descriptor. */ - if (strcmp (bfd_get_section_name (objfile->obfd, sect), ".plt") == 0) + resolution and it has no use for GDB. */ + const char *target_name = MSYMBOL_LINKAGE_NAME (msym.minsym); + size_t len = strlen (target_name); + + /* Note we check the symbol's name instead of checking whether the + symbol is in the .plt section because some systems have @plt + symbols in the .text section. */ + if (len > 4 && strcmp (target_name + len - 4, "@plt") == 0) return 0; htab = (htab_t) objfile_data (objfile, elf_objfile_gnu_ifunc_cache_data); -- 2.14.3