From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
To: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCHv2 08/16] gdb/tui: fix 'tui reg next/prev' command when data window is hidden
Date: Wed, 6 Apr 2022 09:13:41 -0400 [thread overview]
Message-ID: <af998555-06c7-23dd-a836-4c4f1cdc9ddf@polymtl.ca> (raw)
In-Reply-To: <c7da9d2b1ae3b91203b0bf6cb6d329b332fdbe5c.1649246539.git.aburgess@redhat.com>
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
next prev parent reply other threads:[~2022-04-06 13:14 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-31 21:04 [PATCH 00/16] Default register groups, and general related cleanup Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 01/16] gdb: don't try to use readline before it's initialized Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 02/16] gdb: add some const in gdb/reggroups.c Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 03/16] gdb: make gdbarch_register_reggroup_p take a const reggroup * Andrew Burgess via Gdb-patches
2022-04-04 22:35 ` Lancelot SIX via Gdb-patches
2022-04-05 8:24 ` Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 04/16] gdb: switch to using 'const reggroup *' in tui-regs.{c, h} Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 05/16] gdb: use 'const reggroup *' in python/py-registers.c file Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 06/16] gdb: have reggroup_find return a const Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 07/16] gdb/tui: avoid theoretical bug with 'tui reg' command Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 08/16] gdb/tui: fix 'tui reg next/prev' command when data window is hidden Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 09/16] gdb: always add the default register groups Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 10/16] gdb: convert reggroups to use a std::vector Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 11/16] gdb: remove reggroup_next and reggroup_prev Andrew Burgess via Gdb-patches
2022-04-05 23:11 ` Lancelot SIX via Gdb-patches
2022-04-06 12:06 ` Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 12/16] gdb: more 'const' in gdb/reggroups.{c,h} Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 13/16] gdb: make the pre-defined register groups const Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 14/16] gdb: convert reggroup to a C++ class with constructor, etc Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 15/16] gdb: move struct reggroup into reggroups.h header Andrew Burgess via Gdb-patches
2022-03-31 21:04 ` [PATCH 16/16] gdb: update comments throughout reggroups.{c,h} files Andrew Burgess via Gdb-patches
2022-04-06 14:28 ` Simon Marchi via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 00/16] Default register groups, and general related cleanup Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 01/16] gdb: don't try to use readline before it's initialized Andrew Burgess via Gdb-patches
2022-04-06 12:57 ` Simon Marchi via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 02/16] gdb: add some const in gdb/reggroups.c Andrew Burgess via Gdb-patches
2022-04-06 12:58 ` Simon Marchi via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 03/16] gdb: make gdbarch_register_reggroup_p take a const reggroup * Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 04/16] gdb: switch to using 'const reggroup *' in tui-regs.{c, h} Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 05/16] gdb: use 'const reggroup *' in python/py-registers.c file Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 06/16] gdb: have reggroup_find return a const Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 07/16] gdb/tui: avoid theoretical bug with 'tui reg' command Andrew Burgess via Gdb-patches
2022-04-06 13:02 ` Simon Marchi via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 08/16] gdb/tui: fix 'tui reg next/prev' command when data window is hidden Andrew Burgess via Gdb-patches
2022-04-06 13:13 ` Simon Marchi via Gdb-patches [this message]
2022-04-06 12:04 ` [PATCHv2 09/16] gdb: always add the default register groups Andrew Burgess via Gdb-patches
2022-04-06 13:22 ` Simon Marchi via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 10/16] gdb: convert reggroups to use a std::vector Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 11/16] gdb: remove reggroup_next and reggroup_prev Andrew Burgess via Gdb-patches
2022-04-06 14:22 ` Simon Marchi via Gdb-patches
2022-04-06 14:23 ` Simon Marchi via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 12/16] gdb: more 'const' in gdb/reggroups.{c,h} Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 13/16] gdb: make the pre-defined register groups const Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 14/16] gdb: convert reggroup to a C++ class with constructor, etc Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 15/16] gdb: move struct reggroup into reggroups.h header Andrew Burgess via Gdb-patches
2022-04-06 12:04 ` [PATCHv2 16/16] gdb: update comments throughout reggroups.{c, h} files Andrew Burgess via Gdb-patches
2022-04-06 14:34 ` [PATCHv2 00/16] Default register groups, and general related cleanup Simon Marchi via Gdb-patches
2022-04-07 15:16 ` Andrew Burgess via Gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af998555-06c7-23dd-a836-4c4f1cdc9ddf@polymtl.ca \
--to=gdb-patches@sourceware.org \
--cc=aburgess@redhat.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox