From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120491 invoked by alias); 27 Mar 2018 03:31:40 -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 120481 invoked by uid 89); 27 Mar 2018 03:31:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:2007 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Mar 2018 03:31:38 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w2R3VVWH008210 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 26 Mar 2018 23:31:36 -0400 Received: by simark.ca (Postfix, from userid 112) id CB7B61E77A; Mon, 26 Mar 2018 23:31:31 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id D210E1E073; Mon, 26 Mar 2018 23:31:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 27 Mar 2018 03:31:00 -0000 From: Simon Marchi To: Weimin Pan Cc: gdb-patches@sourceware.org Subject: Re: [PATCH2 PR gdb/18071] aarch64: "info addr" command can't resolve TLS variables In-Reply-To: <1522101252-114393-1-git-send-email-weimin.pan@oracle.com> References: <1522101252-114393-1-git-send-email-weimin.pan@oracle.com> Message-ID: <14dfe03b9667658549aeae6b28835f16@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 27 Mar 2018 03:31:31 +0000 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00550.txt.bz2 On 2018-03-26 17:54, Weimin Pan wrote: > Running the test case with upstream gdb shows two failures: > > (1) Receiving different error messages when printing TLS variable > before > program runs - because the ARM compiler does not emit dwarf > attribute > DW_AT_location for TLS, the result is expected and the baseline may > need to be changed for aarch64. > > (2) Using "info address" command on C++ static TLS object resulted in > "symbol unresolved" error - below is a snippet from the test case: > > class K { > public: > static __thread int another_thread_local; > }; > > __thread int K::another_thread_local; > > (gdb) info address K::another_thread_local > Symbol "K::another_thread_local" is unresolved. > > This patch contains fix for (2). > > Function info_address_command() handles the "info address" command and > calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in > minimal symbol table if SYMBOL_COMPUTED_OPS (sym) is false. Problem is > that function lookup_minimal_symbol_and_objfile() only looked up an > objfile's minsym ordinary hash table, not its demangled hash table, > which > was the reason why the C++ name was not found. > > The fix is to replace the lookup_minimal_symbol_and_objfile() call with > the lookup_bound_minimal_symbol() call, which looks up entries in both > minsym's hash tables, via lookup_minimal_symbol(), to find symbol entry > that's associated with the demangled name. Hi Weimin, I don't know if it was clear, but I pushed this patch already: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bce02d8884d6baa72c537d0d7c59f924cb290799 Removing lookup_minimal_symbol_and_objfile and replacing it with lookup_bound_minimal_symbol should be done as a separate patch (with a relevant title that describes the change). Can you do that? There are just a few callers of lookup_minimal_symbol_and_objfile that will need to be updated. Simon