With test-case gdb.dap/sources.exp, I run into:
...
{"request_seq": 4, "type": "response", "command": "source", \
"success": false, "message": "notStopped", \
"seq": 11}FAIL: gdb.dap/sources.exp: get source success
ERROR: tcl error sourcing gdb.dap/sources.exp.
ERROR: key "body" not known in dictionary
...
The FAIL has been filed as PR dap/31374.
The ERROR happens because after the FAIL, dap_check_request_and_response
returns "", and the test-case doesn't check for that.
Fix this by checking for $obj != "" in the test-case.
Tested on x86_64-linux.
When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with
target board unix/-mthumb, we run into:
...
(gdb) reverse-step
func2 () at func-map-to-same-line.c:26
26 {
(gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \
column_info_flag=column-info: step-test: reverse-step into func2
...
The FAIL is caused by incorrect recording of this insn:
...
4f6: f85d 7b04 ldr.w r7, [sp], #4
...
The insn updates the sp, but we don't record this:
...
$ gdb -q -batch func-map-to-same-line \
-ex "b *func2+8" \
-ex run \
-ex record \
-ex "set debug record 2" \
-ex stepi
Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27.
Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27
27 } /* END FUNC2 */
Process record: arm_process_record addr = 0xaaaaa4f6
Process record: add register num = 15 to record list.
Process record: record_full_arch_list_add 0xabc6c460.
Process record: add register num = 7 to record list.
Process record: record_full_arch_list_add 0xabc3b868.
Process record: add register num = 25 to record list.
...
[ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ]
The problem is that the specific insn, an LDR(immediate) T4, is not handled in
thumb2_record_ld_word.
Fix this by detecting the insn in thumb2_record_ld_word, and recording the
updated base register.
Tested on arm-linux.
Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31278
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278
gdb likes to control its own output; for example, this is important
for gdb's pager, and for logging. While BFD provides a way to
intercept error output, via bfd_set_error_handler, it turns out to be
difficult for this function to truly generate the desired output in a
gdb-friendly way -- the error handler is expected to implement some
BFD printf format extensions.
This patch introduces a new function that an error handler can use to
format the text. This way, gdb can set the error handler and arrange
for the output to be displayed as it likes.
* bfd.c (bfd_print_callback): Rename from print_func. Move into
comment.
(_bfd_doprnt): Update.
(bfd_print_error): New function.
(error_handler_fprintf, error_handler_sprintf): Use
bfd_print_error.
* bfd-in2.h: Rebuild.
I noticed that _bfd_doprnt can unconditionally call fputc. However,
when called from error_handler_sprintf, this will likely result in a
crash, as the stream argument does not actually point to a FILE.
* bfd.c (_bfd_doprnt): Do not call fputc.
Commit 433ae2c245 ("[gdb/dap] Catch and log exceptions in dap threads") made
some changes to gdb/python/lib/gdb/dap/startup.py.
Re-format it with black.
When running test-case gdb.dap/eof.exp, it occasionally coredumps.
The thread triggering the coredump is:
...
#0 0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6
#2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
at gdb/event-top.c:926
#3 0x00000000007b0470 in handle_sigsegv (sig=11)
at gdb/event-top.c:976
#4 <signal handler called>
#5 0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=...,
format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232
#6 0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=...,
format=0xffff0c002af1 "%s") at gdb/ui-out.c:584
#7 0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=...,
format=0x16f93ea "", args=...) at gdb/ui-out.c:621
#8 0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...)
at gdb/ui-file.c:74
#9 0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s",
args=...) at gdb/utils.c:1898
#10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s")
at gdb/utils.c:1913
#11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0)
at gdb/python/python.c:1464
#12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
#13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
from /lib64/libpython3.12.so.1.0
#14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
#16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0
#17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0
#18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0
#19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0
#20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O ()
from /lib64/libpython3.12.so.1.0
#21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0
#22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
#24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0
#25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0
#26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6
#27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6
...
The direct cause for the coredump seems to be that cli_ui_out::do_message
is trying to write to a stream variable which does not look sound:
...
(gdb) p *stream
$8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, {
m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}},
m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377',
m_green = 255 '\377', m_blue = 0 '\000'}}},
m_intensity = (unknown: 0x438fe710), m_reverse = 255}}
...
The string that is being printed is:
...
(gdb) p str
$9 = "Exception in thread "
...
so AFAICT this is a DAP thread running into an exception and trying to print
it.
If we look at the state of gdb's main thread, we have:
...
#0 0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6
#1 0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 ()
from /lib64/libc.so.6
#2 0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0
#3 0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread ()
from /lib64/libpython3.12.so.1.0
#4 0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads (
this=0xfffffbea1cf8, __in_chrg=<optimized out>)
at gdb/python/python-internal.h:769
#5 0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60,
kw=0x34553d20) at gdb/python/python.c:681
#6 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
#7 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
from /lib64/libpython3.12.so.1.0
#8 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#9 0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 ()
from /lib64/libpython3.12.so.1.0
#10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900)
at gdb/python/python.c:1061
#11 0x0000000000ab93e8 in std::__invoke_impl<void, gdbpy_event&> (__f=...)
at /usr/include/c++/13/bits/invoke.h:61
#12 0x0000000000ab9204 in std::__invoke_r<void, gdbpy_event&> (__fn=...)
at /usr/include/c++/13/bits/invoke.h:111
#13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...)
at /usr/include/c++/13/bits/std_function.h:290
#14 0x000000000062e0d0 in std::function<void ()>::operator()() const (
this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591
#15 0x0000000000b67f14 in run_events (error=0, client_data=0x0)
at gdb/run-on-main-thread.c:76
#16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1)
at gdbsupport/event-loop.cc:573
#17 0x000000000157e760 in gdb_wait_for_event (block=1)
at gdbsupport/event-loop.cc:694
#18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1)
at gdbsupport/event-loop.cc:264
#19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
#20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
#21 0x000000000094567c in captured_main (data=0xfffffbea23e8)
at gdb/main.c:1335
#22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8)
at gdb/main.c:1354
#23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578)
at gdb/gdb.c:39
...
AFAIU, there's a race between the two threads on gdb_stderr:
- the DAP thread samples the gdb_stderr value, and uses it a bit later to
print to
- the gdb main thread changes the gdb_stderr value forth and back,
using a temporary value for string capture purposes
The non-sound stream value is caused by gdb_stderr being sampled while
pointing to a str_file object, and used once the str_file object is already
destroyed.
The error here is that the DAP thread attempts to print to gdb_stderr.
Fix this by adding a thread_wrapper that:
- catches all exceptions and logs them to dap.log, and
- while we're at it, logs when exiting
and using the thread_wrapper for each DAP thread.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Co-workers at AdaCore pointed out that gdb incorrectly implements the
DAP launch and configurationDone requests. It's somewhat strange to
me, but the spec does in fact say that configuration requests should
occur before the executable is known to gdb. This was clarified in
this bug report against the spec:
https://github.com/microsoft/debug-adapter-protocol/issues/452
Fixing 'launch' to start the inferior was straightforward, but this
then required some changes to how breakpoints are handled. In
particular, now gdb will emit the "pending" reason on a breakpoint,
and will suppress breakpoint events during breakpoint setting.
Kévin pointed out that suppress_new_breakpoint_event would do the
wrong thing if it happened to be used reentrantly. While I don't
think this can happen, it's also easy and clearly better to make it
robust.
The function rs6000_epilogue_frame_cache assumes the LR and gprs have been
restored. In fact register r31 and the link register, lr, may not have
been restored yet. This patch adds support to store the lr and gpr
register unrolling rules in the cache. The LR and GPR values can now be
unrolled correctly.
Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp.
packet_check_result currently returns an packet_result enum.
If GDB will recieve an error in a format E.errtext, which
is possible for some q packets, such errtext is lost if
treated by packet_check_result.
Introduce a new structure which bundles enum packet_result
with possible error message or error code returned by
the GDBserver.
I plan to make more GDBserver response checking functions to use
packet_check_result to make remote.c code more consistent.
This will also allow to use E.errtext more in the future.
Beside adding the unit test, I tested this by modifying
store_registers_using_G function to get an error message:
[remote] Sending packet: $GG00000000 ...
gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793)
gdbserver: Invalid hex digit 71
Killing process(es): 1104002
[remote] Packet received: E01
Could not write registers; remote failure reply '01'
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.
With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that the help text for set/show python ignore-environment
was messed up, some lines had unwanted leading white space, like this:
(gdb) help set python ignore-environment
Set whether the Python interpreter should ignore environment variables.
When enabled GDB's Python interpreter will ignore any Python related
flags in the environment. This is equivalent to passing `-E' to a
python executable.
(gdb)
This has been present since the ignore-environment setting was added
in commit:
commit edeaceda7b
Date: Thu Aug 27 16:53:13 2020 +0100
gdb: startup commands to control Python extension language
Fixed in this commit.
Currently it's not possible to use the value repeat operator on references:
```
print ((int &) v_int_array_init[0])@2
Only values in memory can be extended with '@'.
```
This seems like an unnecessary restriction, since it also prevents
its use on iterators (which was the original reported problem):
```
(gdb) p *it@2
Only values in memory can be extended with '@'.
```
So this converts any references to the referenced value in value_repeat,
making this possible:
```
print ((int &) v_int_array_init[0])@2
$1 = {10, 20}
(gdb) p *it@2
$2 = {1, 2}
```
Approved-by: Kevin Buettner <kevinb@redhat.com>
Since commit 74daa597e7 ("gdb: add all_objfiles_removed observer"), the
objfile passed to the free_objfile observable can't be nullptr.
Change-Id: If215aa051ab43c068b11746938022c7efca09caa
Approved-By: Andrew Burgess <aburgess@redhat.com>
Make the current_program_space reference bubble up one level.
Remove one unnecessary declaration of clear_solib.
Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d
Approved-By: Andrew Burgess <aburgess@redhat.com>
Make the current_program_space reference bubble up one level.
Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e
Approved-By: Andrew Burgess <aburgess@redhat.com>
By inspection, I believe that breakpoint_init_inferior doesn't call
anything that relies on the current program space or inferior. So,
add an inferior parameter, to make the current inferior / program space
references bubble up one level.
Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7
Approved-By: Andrew Burgess <aburgess@redhat.com>
Make the current_program_space reference bubble up one level.
Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29
Approved-By: Andrew Burgess <aburgess@redhat.com>
Since commit 393a6b5947 ("Thread options & clone events (Linux
GDBserver)"), aarch64-linux gdbserver crashes when the inferior
vforks. This happens in aarch64_get_debug_reg_state:
struct process_info *proc = find_process_pid (pid);
return &proc->priv->arch_private->debug_reg_state;
Here, find_process_pid returns nullptr -- the new inferior hasn't yet
been created in linux_process_target::handle_extended_wait.
This patch fixes the problem by having
linux_process_target::handle_extended_wait create the child process
earlier, before the child LWP is created. This is what the function
did before it was reorganized by the commit referred above.
Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50
Co-Authored-By: Tom Tromey <tromey@adacore.com>
Don't wander into three_byte_table[] when REX2 is present.
While there also eliminate related confusion when accessing
dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping
the odd variable gets things better in sync with 1-byte handling as
well.
Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't
even present in the x86-64-apx-egpr-inval testcase, hence why I
overlooked that these can actually be encoded, (again) using suitable
AVX512 counterparts.
While there also "modernize" the adjacent AVX/AVX2 entries.
Already the %bnd<N> registers used numbers beyond 127, and eGPR ones are
all out of reach for "signed char", at least when CHAR_BITS=8. Switch to
"unsigned char", covering appropriately in places where the value
returned for "none" actually matters (in tc_x86_parse_to_dw2regnum()
this is actually achieved by altering how X_op is set).
It has been observed that the run of scfi-unsupported-1 test with --x32
arg on a Solaris2 x86_64 system fails:
Executing on host: sh -c {../as-new --x32 --scfi=experimental \
<...>/scfi-unsupported-1.s 2>&1} /dev/null dump.out (timeout = 300)
Assembler messages:
Fatal error: no compiled in support for 32bit x86_64
regexp_diff match failure
regexp "^Fatal error: SCFI is not supported for this ABI$"
line "Fatal error: no compiled in support for 32bit x86_64"
FAIL: x86_64 scfi-unsupported-1
Fix the above by adding a check for --x32 support before running the
test. While at it, also include a similar check for --32 support.
gas/testsuite/
* gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and
gas_32_check. Conditionalize the execution of affected
testcases.
Like https://sourceware.org/pipermail/binutils/2002-August/021279.html
but for symbols defined in an xcoff object but then made absolute by a
linker script.
* xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly
for symbols made absolute by a linker script.
gdb.base/default.exp has an incomplete test for the "info copying" command,
as poetically pointed out by the FIXME removed by this patch.
The test omits the pattern argument to gdb_test, which causes it to just
check for a GDB prompt at the end of the command output.
The problem is that the command output is the whole GPLv3 license, which
due to its size causes the test to fail sometimes, making the testcase to
be out of sync with GDB's output and failing the tests that follow
it. E.g.,
FAIL: gdb.base/default.exp: info copying (timeout)
FAIL: gdb.base/default.exp: info display
FAIL: gdb.base/default.exp: info frame "f" abbreviation
PASS: gdb.base/default.exp: info frame
FAIL: gdb.base/default.exp: info files
FAIL: gdb.base/default.exp: info float
FAIL: gdb.base/default.exp: info functions
FAIL: gdb.base/default.exp: info locals
FAIL: gdb.base/default.exp: info program
FAIL: gdb.base/default.exp: info registers
FAIL: gdb.base/default.exp: info stack "s" abbreviation
Fix by by checking for a few excerpts at the beginning, middle and end of
the license text. This makes the test consume the command's output in
smallish chunks.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
In https://sourceware.org/pipermail/binutils/2007-August/053261.html
(git commit 3dea8fca8b) I disabled a then new linker feature that
removed empty PT_LOAD headers in cases where a user specified program
headers, and for objcopy. This can be a problem for objcopy/strip and
since objcopy operates on sections, any part of a PT_LOAD loading file
contents not covered by a section will be omitted anyway.
PR 31208
* elf.c (_bfd_elf_map_sections_to_segments): Pass remove_empty_load
as true to elf_modify_segment_map for objcopy/strip.
When the inferior exits, the TUI register window should clear.
Fixing this was mostly a matter of sticking an assignment into
tui_inferior_exit. However, some changes to the register window
itself were also needed.
While working on this, I realized that the TUI register window would
not work correctly when moving between frames of different
architectures. This patch attempts to fix this as well, though I have
no way to test it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This renames a method on the TUI register window to reflect its real
purpose.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Nothing uses the tui_show_frame_info result any more, so change it to
return void.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
tui_refresh_frame_and_register_information checks 'from_stack' in a
block that's already guarded by a 'from_stack' check. This patch
removes the redundant check.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The comment by tui_refreshing_registers mentions a hook that no longer
exists. However, maybe the comment is wrong.
The code paths touching tui_refreshing_registers can only be called in two places:
1. From the before_prompt observer. This is only called when a prompt
is about to be displayed.
2. From the register_changed observer. This is only called when
value_assign changes a register value.
From this it seems clear that the recursion case here cannot in fact
occur. This patch removes the variable.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
There's only a single call to tui_data_win::erase_data_content now, so
remove the parameter and make it just render the "empty window" text.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
After these restructurings, it should be clear that the rerender
overload can be removed from the TUI register window. This is done by
moving a bit more logic from show_registers into update_register_data.
After this, update_register_data simply updates the internal state,
and rerender will write to the screen. All the actual rendering work
is done, ultimately, by display_registers_from. This split between
updating the model and rendering makes it clear that the recursive
case can't happen any longer.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This changes update_register_data to always update the register data.
The idea here is that this is really only called when either the
desired register group changes, or when gdb transitions from not
having a frame to having a frame.
show_registers is also simplified slightly to account for this.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The register window calls scrollok each time a register is written to
the window. However, we only need to call this once, at the start of
display. (We could actually call it just once when the window is
made, but that would involve making another method virtual or adding a
new member -- both which I think are worse than this approach.)
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
tui_register_info::visible is redundant with the fact that y==0 means
that the register is not visible. This patch changes this member in
favor of having a single indication of the register's visibility -- a
method with the same name. This change makes it clear that
delete_data_content_windows is not needed, so this is removed as well.
Approved-By: Andrew Burgess <aburgess@redhat.com>
tui_data_item_window used to hold a curses window, but we removed that
ages ago. Now it just holds information about a single register.
This patch renames the class to make it more clearly reflect its
meaning.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This simplifies tui_data_window::show_register_group, renaming it as
well. The old method had two loops to iterate over all the registers
for the arch, but in the new scheme, the vector is set up when
switching groups, and then updates simply iterate over the vector.
tui_data_item_window is made self-updating, which also clarifies the
code somewhat.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This changes a couple of spots to use nullptr rather than 0, and
changes an int to a bool.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
tui_register_format can use string::pop_back now.
Tested-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
