From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id HqtSBSySTWLfNAAAWB0awg (envelope-from ) for ; Wed, 06 Apr 2022 09:14:20 -0400 Received: by simark.ca (Postfix, from userid 112) id 05DB41F344; Wed, 6 Apr 2022 09:14:20 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7DE101ED17 for ; Wed, 6 Apr 2022 09:14:19 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D20D9385DC31 for ; Wed, 6 Apr 2022 13:14:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D20D9385DC31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649250858; bh=0XTr5+Gnf7iC9t1lwETciATWxLcZVzBm0zebYkHD8X8=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=yZXAv1N92t2k98vPVrRr2HCQ4WBmjqyPYBQGXwGdr7cz/KbLULJp011cdOjBxclIn biIWO5EH/44gqK5A676WVVFA9UqCcD0eWRCTRaLZiw391Q03RlIkCvbF2Q5ggGIJql YguF7Z3dPxV8bbof7Rab/faiyZxqD4x3VAHIkgdQ= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id DF68F3857815 for ; Wed, 6 Apr 2022 13:13:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF68F3857815 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 236DDfK9005040 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 09:13:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 236DDfK9005040 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 510AE1ED17; Wed, 6 Apr 2022 09:13:41 -0400 (EDT) Message-ID: Date: Wed, 6 Apr 2022 09:13:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCHv2 08/16] gdb/tui: fix 'tui reg next/prev' command when data window is hidden Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 6 Apr 2022 13:13:41 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-04-06 08:04, Andrew Burgess via Gdb-patches wrote: > Start GDB like: > > $ gdb -q executable > (gdb) start > (gdb) layout src > ... tui windows are now displayed ... > (gdb) tui reg next > > At this point the data (register) window should be displayed, but will > contain the message 'Register Values Unavailable', and at the console > you'll see the message "unknown register group 'next'". > > The same happens with 'tui reg prev' (but the error message is > slightly different). > > At this point you can continue to use 'tui reg next' and/or 'tui reg > prev' and you'll keep getting the error message. > > The problem is that when the data (register) window is first > displayed, it's current register group is nullptr. As a consequence > tui_reg_next and tui_reg_prev (tui/tui-regs.c) will always just return > nullptr, which triggers an error in tui_reg_command. > > In this commit I change tui_reg_next and tui_reg_prev so that they > instead return the first and last register group respectively if the > current register group is nullptr. > > So, after this, using 'tui reg next' will (in the above case) show the > first register group, while 'tui reg prev' will display the last > register group. I don't have a strong opinion on this, but my understanding of the current code is that tui_reg_next / tui_reg_prev expect that if the reg window is displayed, there is a current group. So one fix could also be to make sure the tui_regs_layout call selects an initial reggroup, and then tui_reg_next / tui_reg_prev would work as expected. Hmm however, that would give a slightly different behavior. When the tui reg window is not shown and you do "tui reg next", which register group do you want to show? With your solution, we will show the first group. With my proposal, we would show the second. I think that showing the first group makes more sense, so I agree with your solution actually. But then I wonder if "tui reg prev" should behave the same, show the first group. Not really important though, I doubt that anybody will ever care much about that detail in the behavior of the "tui reg prev" command. The patch LGTM. Simon