From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41942 invoked by alias); 30 Oct 2018 21:21:33 -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 41933 invoked by uid 89); 30 Oct 2018 21:21:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=UD:xyz, wondered, descriptive X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Oct 2018 21:21:31 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3CA69C058CA2; Tue, 30 Oct 2018 21:21:30 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EB20886FDF; Tue, 30 Oct 2018 21:21:29 +0000 (UTC) Subject: Re: [PATCH][gdb/symtab] Fix language of duplicate static minimal symbol To: Tom de Vries , gdb-patches@sourceware.org References: <20181030191142.GA13785@delia> From: Keith Seitz Message-ID: <07e42727-0d74-7f04-ef7c-39e180f71da8@redhat.com> Date: Tue, 30 Oct 2018 21:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181030191142.GA13785@delia> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00727.txt.bz2 On 10/30/18 12:11 PM, Tom de Vries wrote: > However, when we use gdb to print info on foo, both foos are listed, but we > get one symbol mangled and one symbol demangled: > ... > $ gdb ./a.out -batch -ex "info func foo" > All functions matching regular expression "foo": > > Non-debugging symbols: > 0x00000000004004c7 foo() > 0x00000000004004dd _ZL3foov > ... > Good catch! > Build and reg-tested on x86_64-linux. > > OK for trunk? I have just a few comments. > 2018-10-30 Tom de Vries > > * symtab.c (symbol_set_names): Call symbol_find_demangled_name > unconditionally, to get the language of the symbol. s/get/set/ ? When reading the patch, I originally wondered how that would help, but symbol_find_demangled_name actually *sets* the gsymbol's language if it is language_auto. > > * gdb.base/msym.c: New test. > * gdb.base/msym.exp: New file. > * gdb.base/msym_main.c: New test. These entries should be listed under the testsuite ChangeLog, like: testsuite/ChangeLog: YYYY-MM-DD .... * gdb.xyz/file1.c: ... * gdb.xyz/file1.exp: .... [https://sourceware.org/gdb/wiki/ContributionChecklist#Properly_Formatted_GNU_ChangeLog] "msym.c" et al aren't particularly descriptive, though. Can we devise a better, more explicit name? Something along the lines of "multiple-language-msyms.exp". It's long, but it describes things better. [I'm not saying you should use this name, but something other than just "msym.{c,exp}".] Sorry, some of that is kinda nitpicky. > diff --git a/gdb/symtab.c b/gdb/symtab.c > index cd27a75e8c..481428f733 100644 > --- a/gdb/symtab.c > +++ b/gdb/symtab.c > @@ -818,6 +818,10 @@ symbol_set_names (struct general_symbol_info *gsymbol, > else > linkage_name_copy = linkage_name; > > + /* Set the symbol language. */ > + char *demangled_name = symbol_find_demangled_name (gsymbol, > + linkage_name_copy); > + > entry.mangled = linkage_name_copy; > slot = ((struct demangled_name_entry **) > htab_find_slot (per_bfd->demangled_names_hash, symbol_find_demangled_name returns a malloc'd string which will leak here unless the code goes through the branch. You'll need to save the result into a unique_xmalloc_ptr and adjust the code accordingly. Otherwise, LGTM. Thanks very much for the patch. Keith (IANAM*) * I am not a maintainer, you'll need to await final review by a global maintainer.