From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11745 invoked by alias); 28 Feb 2020 14:11:16 -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 11736 invoked by uid 89); 28 Feb 2020 14:11:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy=H*f:sk:5171842, non-general, c9c895b9666, Feel X-HELO: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Feb 2020 14:11:14 +0000 Received: by mail-ot1-f65.google.com with SMTP id j20so2681721otq.3 for ; Fri, 28 Feb 2020 06:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=36UbywSDkg5Gkn4ow5iAMt+ZmLzStn5IZSf2DUjATeY=; b=YKYg8mGtrCnVpW0uZ3TPYxAi+k99gBAB9/B2w3nNYOakY5EQqxFURhm0fc9bqqo1p/ opG0twmDJ03X+t9OpMB8LVDb09FemVSPwfR5Yd+3kB/SHZLk00SNtY26ev0px3t0g89o JTu3N45YDK6kQlCBL1ABodO05BEaChG7OnRmNb+1FY+m1cUybxv7uxwjSaiEAfu/rsht TfP3SvytSQ0uABucTr4FJiQX/8BeYe1VPYgflHbst5cyY+QAdfllQXDj/rW+Xx2X3w7w kBtJnPgsI18+sC1hxLEtpT+4seBLA7mBWQaUO32jJzAQy6LR3Oac8gaMUCe4bJxniehB eslw== MIME-Version: 1.0 References: <20200120155315.30333-1-shahab.vahedi@gmail.com> <75f76108-a233-6fce-66a2-86452371e1be@linaro.org> <9c256b27-4a00-8830-46e2-934922e39cc2@linaro.org> <20200228133618.GA3269@gmail.com> <51718427-72e2-ce12-7181-26ec9b38d947@linaro.org> <20200228140801.GB3269@gmail.com> In-Reply-To: <20200228140801.GB3269@gmail.com> From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Fri, 28 Feb 2020 14:11:00 -0000 Message-ID: Subject: Re: [Regression] [PATCH] Do not print empty-group regs when printing general ones To: Shahab Vahedi Cc: Luis Machado , Shahab Vahedi , "gdb-patches@sourceware.org" , Claudiu Zissulescu , Francois Bedard , Andrew Burgess Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg01047.txt.bz2 On Fri, Feb 28, 2020 at 8:08 AM Shahab Vahedi wrote: > > On Fri, Feb 28, 2020 at 10:50:54AM -0300, Luis Machado wrote: > > On 2/28/20 10:36 AM, Shahab Vahedi wrote: > > > On Fri, Feb 28, 2020 at 10:31:26AM -0300, Luis Machado wrote: > > > > > > > > > > > > On 2/28/20 10:22 AM, Christian Biesinger wrote: > > > > > On Fri, Feb 28, 2020 at 7:08 AM Luis Machado wrote: > > > > > > > > > > > > On 1/31/20 7:34 AM, Shahab Vahedi wrote: > > > > > > > This patch was reviewed once (as OK): > > > > > > > https://sourceware.org/ml/gdb-patches/2020-01/msg00613.html > > > > > > > > > > > > > > Could someone review/merge it? > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > Shahab > > > > > > > > > > > > > > > > > > > FTR, this has broken general register printing for ARM/AArch64. Now > > > > > > "info reg" shows nothing. > > > > > > > > > > > > Given there are already remote stubs, probes and gdbservers running out > > > > > > there, this is an undesirable change to have. > > > > > > > > > > > > I had an IRC chat with Christian and he pointed me at some documentation > > > > > > stating empty-group registers should not be printed, but i think this is > > > > > > a case where the implementation has diverged from the documentation. > > > > > > > > > > > > https://sourceware.org/gdb/current/onlinedocs/gdb/Target-Description-Format.html#Target-Description-Format > > > > > > > > > > > > We could probably patch up any non-standard target description XML's > > > > > > from now on, but the existing behavior may have to be preserved. > > > > > > > > > > Most targets under features/ do not specify group="general" in their > > > > > XML files for anything (only S/390 does); it seems like that should > > > > > maybe be fixed either way? > > > > > > > > I agree. > > > > > > The documentation [1] says: > > > If no group is specified, GDB will not display the register in info registers > > > > > > [1] > > > https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html#Target-Description-Format > > > > > > > That's valid, but unfortunately it doesn't change the fact the existing code > > is breaking backwards compatibility with the installed base. > > > > As we discussed on IRC, this is code put together in early 2007 and hasn't > > been touched since, apart from a small change in 2017 to cope with arbitrary > > group strings. Plus we have plenty of existing target descriptions that do > > not honor explicitly setting a register group. > > > > With that said, i think the documentation would have a lower priority in > > this regard. We should fix the existing target descriptions to be more > > strict with the group names, but the old behavior would have to be honored > > IMO. > > I agree. The point in the patch was to make extra registers go away. However, > it apparently eliminated the output of "info registers" for other targets and > that is not OK. No matter sticking to the documentation or not. Feel free to > revert the patch. > > Ideally I'd like a solution that: > > 1) "info registers": must not print the non-default (non-general) registers > as it was the case with c9c895b9666 > > 2) "info registers": should only print "general" group registers. This requires > adding 'group="general"' to every XML features out there. So I don't know > how realistic it is. Maybe we can do something like: if there is no register with group=general, print all registers w/o group. Otherwise, only print registers with group=general. Christian