From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 9F8CD386F430 for ; Fri, 19 Jun 2020 02:18:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9F8CD386F430 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Sandra_Loosemore@mentor.com IronPort-SDR: rL7mcFifYb05atZ+yFDFPEN9hnqILBYuy/fOKIpos7TrbQIe5STq0EciQg1kgLzbgQ3xPK7BoC 9lvJ29Z/WwQiakRgteblS4Qig4ecXbA216wlUcZyW9ouRv6tLd+wcDkekaiHnKv2Gax3g3CWIv n21bGDC9NQostF2JuknNSMHVOxUPjhL6yzIBPqvXo45Jzkx4WsOB9wuUXvLN76vW7acAlLKNBQ +CZbt6TqEbxDWy/uSNR5HovBybYAuQvhK2oPAniVhqLYn5LlYNBwvpmVIkVWy7oV7TZpXcN4R8 HOU= X-IronPort-AV: E=Sophos;i="5.75,253,1589270400"; d="scan'208";a="49992147" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 18 Jun 2020 18:18:26 -0800 IronPort-SDR: Ga/IqrZjWmdoBIIejm1hmSq6Vao52NbXhP7soFauha3wWDypvUVWnRB4OobIuoB97ODDYwmLbR 1p4mu8apRQ0tRhFxX+e2zH0Kw8DPfKiejT1dPTiP59FuyY5OcnkTxkq9NjbUj+uZ+ImNnJ8MYP RW2wUCBPjU0qvJnwsYjLGselBLxUQt1ZBLJbn1qZoGo1/okpJVe6VwMFmRjg4XmJr/TVBJig+o OH/gKBhU/4tK4PiSnOHfu0jR2Y3jssGM3Uu/ywo5ckqkb/EDEWzeLuGTrZFONKhLNDTNKQZnpc rX0= Subject: Re: [patch] gdb/testsuite: fixes for gdb.xml/tdesc-regs.exp To: Andrew Burgess CC: "gdb-patches@sourceware.org" References: <71c00a14-a956-a087-8b9a-9b453194d4f2@codesourcery.com> <20200616204701.GT2737@embecosm.com> <369fc78b-2e7c-545d-fc19-53193fa93f64@codesourcery.com> <20200618094337.GX2737@embecosm.com> From: Sandra Loosemore Message-ID: <104278ce-a730-2a59-dcf2-cb76fc6646d9@codesourcery.com> Date: Thu, 18 Jun 2020 20:18:18 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200618094337.GX2737@embecosm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-08.mgc.mentorg.com (147.34.90.208) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 02:18:29 -0000 On 6/18/20 3:43 AM, Andrew Burgess wrote: > * Sandra Loosemore [2020-06-16 15:08:59 -0600]: > >> On 6/16/20 2:47 PM, Andrew Burgess wrote: >> >>> I'd be interested to know more about which targets don't place any >>> registers in the 'general' group. This group is used in >>> default_print_registers_info to implement 'info registers', so I'd >>> like to see what this particular target has done instead. >> >> nios2, for one. From the original test log for nios2-linux-gnu: > > OK, but... > > Please bear with me, I don't have a nios2 tool chain to hand, but... > > In nios2-tdep.c, there is no call to set_gdbarch_print_registers_info, > which means (from gdbarch.c) that nios2 will use > default_print_registers_info. > > Now if we look in infcmd.c at both default_print_registers_info and > registers_info, then we see that if a user says: > > (gdb) info registers > > then they will be asking which registers are in the general_reggroup. > > Now, nios can optionally use a remote target-description (from > nios2_gdbarch_init), so, lets for now assume no target description. I > see no call to set_gdbarch_register_reggroup_p for nios2, which means > we are going to be using default_register_reggroup_p, which if we > inspect (in reggroups.c) we'll see does place some registers into the > general group. > > Now, does this matter? The reggroup name is never printed anywhere, we > just see a set of random registers? > > But it is annoying that the user is not easily able to say: > > (gdb) info registers general > > and get the same output. > > If we look at how other targets deal with this most of them manually > add at least some sub-set of the default register groups to their > architectures set of register groups as part of their _gdbarch_init > routine. > > My gut instinct here is that this is what nios2 should be doing (and > maybe arm too). > > It does seem odd that there's no central "add-the-default-reggroups" > type routine that targets can or should call. OK. How about I commit the other two pieces of the patch (which seem like genuine bugs in the testcase), and treat this one as uncovering a bug in the implementation instead of just an inappropriate x86-specific assumption wired into the testcase? -Sandra