Message ID | 1522101252-114393-1-git-send-email-weimin.pan@oracle.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 114212 invoked by alias); 26 Mar 2018 22:20:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 114202 invoked by uid 89); 26 Mar 2018 22:20:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_STOCKGEN, SPF_PASS, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=Pan, Hx-languages-length:2467, pan X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Mar 2018 22:20:25 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2QMI2CW192217 for <gdb-patches@sourceware.org>; Mon, 26 Mar 2018 22:20:23 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2gy9hhg08s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gdb-patches@sourceware.org>; Mon, 26 Mar 2018 22:20:23 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2QMKMh1008778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gdb-patches@sourceware.org>; Mon, 26 Mar 2018 22:20:23 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2QMKM4V023387 for <gdb-patches@sourceware.org>; Mon, 26 Mar 2018 22:20:22 GMT Received: from wmpan.us.oracle.com (/10.147.27.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Mar 2018 15:20:22 -0700 From: Weimin Pan <weimin.pan@oracle.com> To: gdb-patches@sourceware.org Subject: [PATCH2 PR gdb/18071] aarch64: "info addr" command can't resolve TLS variables Date: Mon, 26 Mar 2018 15:54:12 -0600 Message-Id: <1522101252-114393-1-git-send-email-weimin.pan@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8844 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=907 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803260221 |
Commit Message
Weimin Pan
March 26, 2018, 9:54 p.m. UTC
Running the test case with upstream gdb shows two failures: (1) Receiving different error messages when printing TLS variable before program runs - because the ARM compiler does not emit dwarf attribute DW_AT_location for TLS, the result is expected and the baseline may need to be changed for aarch64. (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). Function info_address_command() handles the "info address" command and calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in minimal 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. The fix is to replace the lookup_minimal_symbol_and_objfile() call with the lookup_bound_minimal_symbol() call, which looks up entries in both minsym's hash tables, via lookup_minimal_symbol(), to find symbol entry that's associated with the demangled name. Tested in both aarch64-linux-gnu and amd64-linux-gnu. No regressions. --- gdb/ChangeLog | 8 ++++++++ gdb/printcmd.c | 2 +- 2 files changed, 9 insertions(+), 1 deletions(-)
Comments
On 2018-03-26 17:54, Weimin Pan wrote: > Running the test case with upstream gdb shows two failures: > > (1) Receiving different error messages when printing TLS variable > before > program runs - because the ARM compiler does not emit dwarf > attribute > DW_AT_location for TLS, the result is expected and the baseline may > need to be changed for aarch64. > > (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). > > Function info_address_command() handles the "info address" command and > calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in > minimal 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. > > The fix is to replace the lookup_minimal_symbol_and_objfile() call with > the lookup_bound_minimal_symbol() call, which looks up entries in both > minsym's hash tables, via lookup_minimal_symbol(), to find symbol entry > that's associated with the demangled name. Hi Weimin, I don't know if it was clear, but I pushed this patch already: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bce02d8884d6baa72c537d0d7c59f924cb290799 Removing lookup_minimal_symbol_and_objfile and replacing it with lookup_bound_minimal_symbol should be done as a separate patch (with a relevant title that describes the change). Can you do that? There are just a few callers of lookup_minimal_symbol_and_objfile that will need to be updated. Simon
On 3/26/2018 8:31 PM, Simon Marchi wrote: > On 2018-03-26 17:54, Weimin Pan wrote: >> Running the test case with upstream gdb shows two failures: >> >> (1) Receiving different error messages when printing TLS variable before >> program runs - because the ARM compiler does not emit dwarf >> attribute >> DW_AT_location for TLS, the result is expected and the baseline may >> need to be changed for aarch64. >> >> (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). >> >> Function info_address_command() handles the "info address" command and >> calls lookup_minimal_symbol_and_objfile() to find sym's symbol entry in >> minimal 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. >> >> The fix is to replace the lookup_minimal_symbol_and_objfile() call with >> the lookup_bound_minimal_symbol() call, which looks up entries in both >> minsym's hash tables, via lookup_minimal_symbol(), to find symbol entry >> that's associated with the demangled name. > > Hi Weimin, > > I don't know if it was clear, but I pushed this patch already: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bce02d8884d6baa72c537d0d7c59f924cb290799 > > > Removing lookup_minimal_symbol_and_objfile and replacing it with > lookup_bound_minimal_symbol should be done as a separate patch (with a > relevant title that describes the change). Can you do that? There > are just a few callers of lookup_minimal_symbol_and_objfile that will > need to be updated. > Hi Simon, Yes, I will do another patch get rid of all lookup_minimal_symbol_and_objfile calls. Weimin > Simon
diff --git a/gdb/ChangeLog b/gdb/ChangeLog index fe4ae9f..5faa37b 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,11 @@ +2018-03-22 Weimin Pan <weimin.pan@oracle.com> + + PR gdb/18071: + * printcmd.c (info_address_command): Replace + lookup_minimal_symbol_and_objfile call with + lookup_bound_minimal_symbol call to find symbol entry + of a demangled name. + 2018-03-19 Pedro Alves <palves@redhat.com> Tom Tromey <tom@tromey.com> diff --git a/gdb/printcmd.c b/gdb/printcmd.c index dd81d8f..06038cd 100644 --- a/gdb/printcmd.c +++ b/gdb/printcmd.c @@ -1564,7 +1564,7 @@ info_address_command (const char *exp, int from_tty) { struct bound_minimal_symbol msym; - msym = lookup_minimal_symbol_and_objfile (SYMBOL_LINKAGE_NAME (sym)); + msym = lookup_bound_minimal_symbol (SYMBOL_LINKAGE_NAME (sym)); if (msym.minsym == NULL) printf_filtered ("unresolved"); else