From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24477 invoked by alias); 18 Jan 2018 00:18:11 -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 24424 invoked by uid 89); 18 Jan 2018 00:18:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_STOCKGEN,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*u:6.1, H*UA:6.1 X-HELO: aserp2130.oracle.com Received: from aserp2130.oracle.com (HELO aserp2130.oracle.com) (141.146.126.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Jan 2018 00:18:05 +0000 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0I0Gtn2191278; Thu, 18 Jan 2018 00:18:03 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2fjewf0dke-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Jan 2018 00:18:03 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0I0I234022853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Jan 2018 00:18:03 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0I0I2fN009145; Thu, 18 Jan 2018 00:18:02 GMT Received: from [10.154.158.151] (/10.154.158.151) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jan 2018 16:18:02 -0800 Subject: Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu To: Yao Qi Cc: "gdb-patches@sourceware.org" References: <1509636764-46111-1-git-send-email-weimin.pan@oracle.com> <6eadd01b-098c-ca82-b41a-4303f0f6aa0a@oracle.com> <867eshg231.fsf@gmail.com> From: Wei-min Pan Message-ID: Date: Thu, 18 Jan 2018 00:18:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8777 signatures=668653 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=994 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180002 X-SW-Source: 2018-01/txt/msg00362.txt.bz2 On 1/17/2018 12:55 AM, Yao Qi wrote: > On Wed, Jan 17, 2018 at 1:05 AM, Weimin Pan wrote: >> dwarf2_physname() does call dw2_linkage_name(). But since the class member, >> i.e. another_thread_local, does not contain either DW_AT_linkage_name or >> DW_AT_MIPS_linkage_name attribute, its canonicalized name gets returned. >> > dwarf2_physname is called twice with the parameter NAME is > "another_thread_local". > The first is about DW_TAG_member and the second is about DW_TAG_variable. > > <2><37>: Abbrev Number: 3 (DW_TAG_member) > <38> DW_AT_name : (indirect string, offset: 0x6e): > another_thread_local > <3c> DW_AT_decl_file : 1 > <3d> DW_AT_decl_line : 3 > <3e> DW_AT_type : <0x44> > <42> DW_AT_external : 1 > <42> DW_AT_accessibility: 1 (public) > <43> DW_AT_declaration : 1 > .... > <1><68>: Abbrev Number: 6 (DW_TAG_variable) > <69> DW_AT_specification: <0x37> > <6d> DW_AT_decl_line : 6 > <6e> DW_AT_linkage_name: (indirect string, offset: 0x0): > _ZN1K20another_thread_localE > > The second one matters, not the first one. If I set this breakpoint, > it will hit twice, > > (gdb) b dwarf2_physname if strcmp (name, "another_thread_local") == 0 > > in the 2nd breakpoint hit, you can see dwarf2_physname is called by > new_symbol_full, > > (gdb) bt 5 > #0 dwarf2_physname (name=0x60d0000096fe "another_thread_local", > die=0x621000156ce0, cu=0x612000018340) > at gdb/dwarf2read.c:11183 > #1 0x00000000008f20a9 in new_symbol_full (die=0x621000156ce0, > type=0x0, cu=0x612000018340, space=0x0) > at gdb/dwarf2read.c:21416 > #2 0x00000000008c80a6 in read_variable (die=0x621000156ce0, > cu=0x612000018340) at gdb/dwarf2read.c:14439 > > it returns "K::another_thread_local", and use it to set symbol name. > That symbol > is used in lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)) > later when you type command "info address K::another_thread_local". Yes, the 2nd breakpoint hit in dwarf2_physname() was to handle the DW_TAG_variable die for another_thread_local. The function did fetch the correct mangled name from dw2_linkage_name() and set it in local variable "mangled". Problem is "mangled" got demangled with gdb_demangle(), for the purpose of suppressing C++ template function's return type which I don't quite follow, and the demangled name gets returned.