From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17868 invoked by alias); 22 Mar 2018 04:22:49 -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 17853 invoked by uid 89); 22 Mar 2018 04:22:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Pan, pan, H*F:D*ca, Hx-languages-length:1563 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 04:22:47 +0000 Received: by simark.ca (Postfix, from userid 112) id 19E671E782; Thu, 22 Mar 2018 00:22:46 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id EE2231E4B2; Thu, 22 Mar 2018 00:22:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 22 Mar 2018 04:22:00 -0000 From: Simon Marchi To: Weimin Pan Cc: gdb-patches@sourceware.org, Yao Qi Subject: Re: [PATCH PR gdb/18071] TLS variables can't be resolved on aarch64-linux-gnu In-Reply-To: <6c9fb8cc-eb2a-86c3-9e34-fac7c97f6b2f@oracle.com> References: <1509669516-47946-1-git-send-email-weimin.pan@oracle.com> <402e4a8c-eaf9-a31e-9925-3125f8d149f9@simark.ca> <6c9fb8cc-eb2a-86c3-9e34-fac7c97f6b2f@oracle.com> Message-ID: <8c40379beb8ea8756a3b9075ce6bf4c4@simark.ca> X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.4 X-SW-Source: 2018-03/txt/msg00399.txt.bz2 On 2018-03-19 15:36, Weimin Pan wrote: > Yes, printing of a TLS fails on all platforms, not just on aarch64. > How about changing the title to: > >    [PATCH PR gdb/18071] aarch64: "info" command can't resolve TLS > variables Maybe "info address" instead of "info"? >> Is this code equivalent to calling lookup_minimal_symbol (name, NULL, >> NULL) ? If >> so, there's already lookup_bound_minimal_symbol that does the same, so >> maybe we >> can just drop lookup_minimal_symbol_and_objfile and use >> lookup_bound_minimal_symbol. > > Yes, it turns out lookup_minimal_symbol_and_objfile(name) is equivalent > to > calling lookup_minimal_symbol (name, NULL, NULL). We can replace the > call in > info_address_command() with either lookup_minimal_symbol (name, NULL, > NULL) > or lookup_bound_minimal_symbol(name). Calling either one looks like a > better fix. > >> >> We could also just have lookup_minimal_symbol with parameters that >> default to nullptr. >> It is not clear at all to have lookup_bound_minimal_symbol and >> lookup_minimal_symbol >> that both return a bound_minimal_symbol, that's quite misleading. > > I don't know the rational behind having these two functions which get > called in > quite a few places. Yes, having default arguments for > lookup_minimal_symbol() > will be another option. > > Thanks very much for your comments. Thanks for your patience :). This refactoring can be done in a separate patch, to keep this one focused on fixing the bug. Simon