From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50619 invoked by alias); 29 Nov 2017 01:35: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 50609 invoked by uid 89); 29 Nov 2017 01:35:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=BAYES_00,KAM_STOCKGEN,KB_WAM_FROM_NAME_SINGLEWORD,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*u:6.1, H*UA:6.1, operated, HContent-Transfer-Encoding:8bit 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; Wed, 29 Nov 2017 01:35:20 +0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAT1ZGnP028615 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Nov 2017 01:35:17 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vAT1ZGJG020874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Nov 2017 01:35:16 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vAT1ZGYJ032046; Wed, 29 Nov 2017 01:35:16 GMT Received: from [10.132.97.56] (/10.132.97.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 Nov 2017 17:35: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> <20171121153631.GH318@1170ee0b50d5> From: Weimin Pan Message-ID: <2973d80e-886f-1114-4613-f740f9ce226b@oracle.com> Date: Wed, 29 Nov 2017 01:35: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: <20171121153631.GH318@1170ee0b50d5> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-11/txt/msg00751.txt.bz2 On 11/21/2017 7:36 AM, Yao Qi wrote: > On 17-11-16 14:40:18, Wei-min Pan wrote: >> 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. >> >> > I finally understand what your patches does. It is about finding TLS > variables from msymbol instead of full symbol. It is nothing specific > to aarch64. We've already had a test case gdb.threads/tls-nodebug.exp, > but it is about C, rather than C++. Can you extend this test case for > a C++ TLS (which is mangled)? I expect that GDB can't find the mangled > TLS without debug info on any architecture, and your patch fixes this > issue. If the test is built with no -g, my patch won't be able to find the C++ TLS either.  For example, class foo {  public:   static __thread int total; }; __thread int foo::total = 31; Its mangled name is _ZN3foo5totalE and it's the only way to access the C++ TLS. > > Even with your patch applied, there is still one fail in > gdb.threads/tls.exp, > > -Cannot read `a_thread_local' without registers^M > -(gdb) PASS: gdb.threads/tls.exp: print a_thread_local > +Cannot find thread-local storage for process 0, executable file /home/yao.qi/gnu/build/gdb/testsuite/outputs/gdb.threads/tls/tls:^M > +Cannot find thread-local variables on this target^M > +(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local Please note that the failed "print" command, which operated on a C TLS, was issued before the test program got executed. For arch other than aarch64, the checking of SYMBOL_NEEDS_REGISTERS && target_has_registers was done early and resulted in "without registers" error for program that hasn't started in default_read_var_value(). But for aarch64, it didn't fail until the to_get_thread_local_address() call which caused the "Cannot find thread-local storage" exception. BTW, this was (1) in my original patch report. Thanks. > > Looks GDB error messages in different code patch should be adjusted > as well. >