aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport/ptrace.m4
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-03-31 14:44:25 +0100
committerAndrew Burgess <aburgess@redhat.com>2022-04-07 16:01:18 +0100
commit5783701b36f842b1a5057c02b62d67a0ad703834 (patch)
treef3ac517a2f5fd15f01f5b3814c22373e540f86d0 /gdbsupport/ptrace.m4
parent2b72890eba0373fee1e5c6f6ac0157782222ef3d (diff)
downloadgdb-5783701b36f842b1a5057c02b62d67a0ad703834.zip
gdb-5783701b36f842b1a5057c02b62d67a0ad703834.tar.gz
gdb-5783701b36f842b1a5057c02b62d67a0ad703834.tar.bz2
gdb/tui: avoid theoretical bug with 'tui reg' command
While looking at the 'tui reg' command as part of another patch, I spotted a theoretical bug. The 'tui reg' command takes the name of a register group, but also handles partial register group matches, though the partial match has to be unique. The current command logic goes: With the code as currently written, if a target description named a register group either 'prev' or 'next' then GDB would see this as an ambiguous register name, and refuse to switch groups. Naming a register group 'prev' or 'next' seems pretty unlikely, but, by adding a single else block we can prevent this problem. Now, if there's a 'prev' or 'next' register group, the user will not be able to select the group directly, the 'prev' and 'next' names will always iterate through the available groups instead. But at least the user could select their groups by iteration, rather than direct selection.
Diffstat (limited to 'gdbsupport/ptrace.m4')
0 files changed, 0 insertions, 0 deletions