Re: [PATCH 3/3] Replace TUI's select_frame hook (PR tui/13378)

Patrick Palka
2015-07-01T12:40:03Z

On Tue, Jun 30, 2015 at 1:07 PM, Pedro Alves <palves@redhat.com> wrote:
> On 06/30/2015 05:40 PM, Patrick Palka wrote:
>> [ I elected to go with making the print_frame_info_listing hook a no-op, since
>> it does not seem to regress anything.
>>
>> I noticed that "layout regs" was somewhat broken now that
>> tui_refresh_frame_and_register_information is called twice following a normal
>> stop: once in tui_normal_stop and then in tui_before_prompt. The second call
>> removes any highlights done to the individual registers during the first
>> call, because the function notices that the current snapshot of register
>> values is the same as the one taken during the first call. So effectively
>> register changes are no longer highlighted in "layout regs" since the
>> highlights immediately get removed.
>>
>> I don't think we should refresh register information at all in
>> tui_before_prompt since this observer is intended to only update frame
>> information following a call to "up", "down", "frame", etc. Only after the
>> inferior has run for a bit could registers have changed. So this patch adds
>> the parameter registers_too_p to tui_refresh_frame_and_register_information
>> to indicate wheher we should update registers too, and updates
>> tui_before_prompt and tui_normal_stop accordingly. ]
>
> Hmm, what about when the user changes registers with "print $rax = 1" etc.?
> Do we end up with stale contents?

Unfortunately registers _do_ change following a call to "up", "down"
or "frame", because the snapshot of register values is per-frame. So
this patch introduced a regression -- it made it so that TUI does not
update register information following such a call even though earlier
versions do. I sent a patch to fix this.