From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22979 invoked by alias); 16 Nov 2017 22:40:22 -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 22929 invoked by uid 89); 16 Nov 2017 22:40:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=H*u:6.1, H*UA:6.1 X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Nov 2017 22:40:20 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAGMeH8p014564 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 22:40:18 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vAGMeH5Q016143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 22:40:17 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAGMeHXF018017; Thu, 16 Nov 2017 22:40:17 GMT Received: from [10.159.232.151] (/10.159.232.151) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Nov 2017 14:40:16 -0800 Subject: Re: [PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu To: Yao Qi Cc: gdb-patches@sourceware.org References: <1509669516-47946-1-git-send-email-weimin.pan@oracle.com> <868tf6twly.fsf@gmail.com> From: Wei-min Pan Message-ID: Date: Thu, 16 Nov 2017 22:40:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <868tf6twly.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00327.txt.bz2 On 11/16/2017 1:13 AM, Yao Qi wrote: > Weimin Pan writes: > >> (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). > Why do we need to fix (2)? It is a result of (1). If DW_AT_location is > generated, > > info address K::another_thread_local^M > Symbol "K::another_thread_local" is a thread-local variable at offset 0x4 in the thread-local storage for `gdb/testsuite/outputs/gdb.threads/tls/tls'. > > without DW_AT_location, how does GDB tell where this variable is? The > right fix to me is to fix GCC bug PR 83010, and xfail these tests here > for aarch64. > If a TLS does not have a DW_AT_location, it can still be found in the .tbss section (with flag SEC_THREAD_LOCAL being set) which GLIBC uses for TLS storage and that's what gdb function info_address_command() tries to find by calling lookup_minimal_symbol_and_objfile(). Problem is, as described in the patch, lookup_minimal_symbol_and_objfile() only looked up an objfile's minsym ordinary hash table, not its demangled hash table, and resulted in not finding the C++ name.