From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49094 invoked by alias); 16 Jan 2018 17:12:25 -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 49002 invoked by uid 89); 16 Jan 2018 17:12:24 -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,FREEMAIL_FROM,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:static. X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jan 2018 17:12:22 +0000 Received: by mail-wm0-f48.google.com with SMTP id i11so10060041wmf.4 for ; Tue, 16 Jan 2018 09:12:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=8wvp8scmBro9qlWNP6QSVnFeAJO7DzHeK+SM+R4tZq4=; b=BHW5V7OK5KIodN5seZBmmKNJJQhOuYtkTt3WwVPrdmKKa3A3KupBypfWU2Tjo2b1CI W4rgvO9nM6LuNTltcaDP0WKxRoUVBpF6h5NIVDvWBGNMzAKQrW/5QbexrnHmIvj2b/ql a0nOqnY0EC26sdESl0YvNnk5k5l+73LMUq5VTSB4pIldhASXFxukE6C4Nv2PZWPL2uMC c8daJxLXROhgJCLMQKFJjYLJ1CREyYPatVyC/ZKnyugxmQXf9qGoZQalehttyKLNzUGa mnlnNbAgyXKp14aAjpr+mTShQwvbTlTNNDcRZA0pnKal91sxYY6OlP8M9LGx11R+IV/+ j9VQ== X-Gm-Message-State: AKwxyteTWhkcpPjG0aF2ZohPSe2vjw+wWqdagg8z1Gp3YSnEcA9+cILj LXMdX85un2P4DoepQFAce8aozQ== X-Google-Smtp-Source: ACJfBouvyunjeKLe+YIW7j79kObhgqJqhALguibaykLy8dqJHLOwBmu+FakwjJGbokvAn6TERyqoOQ== X-Received: by 10.28.111.132 with SMTP id c4mr15051088wmi.54.1516122740391; Tue, 16 Jan 2018 09:12:20 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id m18sm3593168wmc.18.2018.01.16.09.12.19 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 16 Jan 2018 09:12:19 -0800 (PST) From: Yao Qi To: Wei-min Pan Cc: "gdb-patches\@sourceware.org" Subject: Re: [PING][PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu References: <1509636764-46111-1-git-send-email-weimin.pan@oracle.com> <6eadd01b-098c-ca82-b41a-4303f0f6aa0a@oracle.com> Date: Tue, 16 Jan 2018 17:12:00 -0000 In-Reply-To: <6eadd01b-098c-ca82-b41a-4303f0f6aa0a@oracle.com> (Wei-min Pan's message of "Wed, 15 Nov 2017 17:53:44 -0800") Message-ID: <867eshg231.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00308.txt.bz2 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 entri= es >> in both minsym's hash tables, to find names when traversing the object f= ile >> 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=3D0x621000136e40 "K::= another_thread_local") at gdb/minsyms.c:1012 1012 unsigned int hash =3D msymbol_hash (name) % MINIMAL_SYMBOL_HASH_SIZE; (gdb) up #1 0x0000000000af7690 in info_address_command (exp=3D0x604000023f5d "K::an= other_thread_local", from_tty=3D1) at gdb/printcmd.c:1567 1567 msym =3D 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 =3D 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. --=20 Yao (=E9=BD=90=E5=B0=A7)