This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tui/13378] gdbtui updates source window for non-stopping conditional breakpoints


https://sourceware.org/bugzilla/show_bug.cgi?id=13378

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bbcbf914a6ad801bfa7d4e56150217a1d53e07af

commit bbcbf914a6ad801bfa7d4e56150217a1d53e07af
Author: Patrick Palka <patrick@parcs.ath.cx>
Date:   Wed Jul 1 08:02:09 2015 -0400

    TUI: Make sure to update registers if frame information has changed

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]