When I replaced TUI's frame_changed hook to fix PR tui/13378 I assumed
that there's no reason to refresh register information following a call
to "up", "down" or "frame". This assumption was made to fix the problem
of refreshing frame information twice following a sync-execution normal
stop (once in tui_normal_stop and then in tui_before_prompt) -- the
second refresh removing any highlights made by the first.
I was wrong about that -- GDB's snapshot of register information is
per-frame, and when the frame changes, registers do too (most
prominently the %rip and %rsp registers). So e.g. GDB 7.8 would
highlight such register changes after invoking "up", "down" or "frame",
and current GDB does not.
To fix this regression, this patch adds another (sufficient) condition
for refreshing register information: in
tui_refresh_frame_and_register_information, always refresh register
information if frame information has changed. This makes register
information get refreshed following a call to "up", "down" or "frame"
while still avoiding the "double refresh" issue following a normal stop.
This condition may seem to obsolete the existing registers_too_p
parameter, but it does not: following a normal stop, it is possible that
registers may have changed while frame information had not. We could be
on the exact same PC with different register values. The new condition
would not catch such a case, but the registers_too_p condition will. So
both conditions seem necessary (and either one is sufficient).
gdb/ChangeLog:
* tui/tui-hooks.c (tui_refresh_frame_and_register_information):
Update commentary. Always refresh the registers when frame
information has changed.
* tui/tui-stack.c (tui_show_frame_info): Update commentary.
Change return type to int. Return 1 if frame information has
changed, 1 otherwise.
(tui_before_prompt): Update commentary.
* tui/tui-stack.h (tui_show_frame_info): Change return type to
int.
bbcbf914a6