From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75857 invoked by alias); 17 Jan 2018 01:05:50 -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 75841 invoked by uid 89); 17 Jan 2018 01:05:49 -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, HContent-Transfer-Encoding:8bit 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; Wed, 17 Jan 2018 01:05:48 +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 w0H12jaV168851; Wed, 17 Jan 2018 01:05:45 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2fhsdqgmb8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Jan 2018 01:05:45 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0H15jjR024973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 17 Jan 2018 01:05:45 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0H15iNe002829; Wed, 17 Jan 2018 01:05:44 GMT Received: from [10.132.96.98] (/10.132.96.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Jan 2018 17:05:44 -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: Weimin Pan Message-ID: Date: Wed, 17 Jan 2018 01:05: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: <867eshg231.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8776 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801170013 X-SW-Source: 2018-01/txt/msg00323.txt.bz2 On 1/16/2018 9:12 AM, Yao Qi wrote: > Wei-min Pan writes: > >>> Function info_address_command() handles the "info address" command and >>> calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in >>> mininal 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. > lookup_minimal_symbol_and_objfile is documented as "only checks the > linkage name" in minsyms.h, > > /* Find the minimal symbol named NAME, and return both the minsym > struct and its objfile. This only checks the linkage name. */ > > struct bound_minimal_symbol lookup_minimal_symbol_and_objfile (const char *); > >>> The fix is to call lookup_minimal_symbol(), which already looks up entries >>> in both minsym's hash tables, to find names when traversing the object file >>> list in lookup_minimal_symbol_and_objfile(). > so, it is incorrect to extend it to search demangled name. If I set a > breakpoint on lookup_minimal_symbol_and_objfile, > > (gdb) info address K::another_thread_local > > Breakpoint 1, lookup_minimal_symbol_and_objfile (name=0x621000136e40 "K::another_thread_local") at gdb/minsyms.c:1012 > 1012 unsigned int hash = msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; > (gdb) up > #1 0x0000000000af7690 in info_address_command (exp=0x604000023f5d "K::another_thread_local", from_tty=1) > at gdb/printcmd.c:1567 > 1567 msym = lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)); > > The problem to me is that why SYMBOL_LINKAGE_NAME (sym) is > "K::another_thread_local", which is a demangled one. The symbol's name > is set in dwarf2read.c:new_symbol_full, > > /* Cache this symbol's name and the name's demangled form (if any). */ > SYMBOL_SET_LANGUAGE (sym, cu->language, &objfile->objfile_obstack); > linkagename = dwarf2_physname (name, die, cu); > SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile); > > however, dwarf2_physname doesn't return the linkage name, so the > symbol's linkagename is set incorrectly. I think the right fix would be > call other function to get linkagename, maybe, dw2_linkage_name? I > don't know. 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.