From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65899 invoked by alias); 26 Jun 2015 03:16:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 65886 invoked by uid 89); 26 Jun 2015 03:16:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ob0-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 26 Jun 2015 03:15:58 +0000 Received: by obbop1 with SMTP id op1so59315210obb.2 for ; Thu, 25 Jun 2015 20:15:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i+XzwIuc8AfS4K7MedVnOIE2ZpGjUkKFC1gGj91GTF0=; b=l4m4C8hUqy0MbmFrAoSsw3iVqU76kbM3nsImrMbOuQDMXzf9nWf0q/0GtuYS38QYEG Hh3nTk3+2zo+bgFOXY96uvfs/V6kKlMUhqLJRACu1Usjdvo6Izb9Cci9Y2k/kyQi+qU9 nunvjbhs0R+ofYezJ+KE812rRmiec4snFO9AVJHWPdsE1nIV009TW4haU6kB/5pr+P+s LCb99PT5jJO8qS+ckHyc4izuLcBiDsPEbx/4up3G6l6nw6qG2HgPMNpu2uAmSTO3chKD iNwHLttw2zNQl3s/1dmVOvK584xoP03HH3DdEInqu95EdccYPCol5IY8s84EVb+BPmD7 yy1w== X-Gm-Message-State: ALoCoQlpodkN3TXZ/OGclHyV5K/D1MPyRBSOBrKsTUiQFo/+w+b89/xZyMFJTE1esk91h2B9ccbT X-Received: by 10.60.67.132 with SMTP id n4mr8973659oet.85.1435288556428; Thu, 25 Jun 2015 20:15:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.167 with HTTP; Thu, 25 Jun 2015 20:15:36 -0700 (PDT) In-Reply-To: References: <1434688566-2549-1-git-send-email-patrick@parcs.ath.cx> From: Patrick Palka Date: Fri, 26 Jun 2015 03:16:00 -0000 Message-ID: Subject: Re: [PATCH] Fix TUI flicker resulting from frequent frame changes (PR tui/13378) To: "gdb-patches@sourceware.org" Cc: Patrick Palka Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg00560.txt.bz2 On Fri, Jun 19, 2015 at 1:13 PM, Patrick Palka wrote: > On Fri, Jun 19, 2015 at 12:36 AM, Patrick Palka wrote: >> This patch fixes the perceived flicker of the TUI screen (and subsequent >> slowdown) that most apparent when running an inferior while a >> conditional breakpoint is active. The cause of the flicker is that each >> internal event GDB responds to is accompanied by a multitude of calls to >> select_frame() and each such call forces the TUI screen to be refreshed. >> We would like to not update the TUI screen after each such frame change. >> >> The fix for this issue is pretty straightforward: do not update the TUI >> screen when select_frame() gets called while synchronous execution of >> the inferior is enabled. This works because synchronous execution >> remains enabled during the processing of internal events. And since >> during synchronous execution the user has no control of the TUI anyway, >> it does not hurt to avoid updating the screen then. >> >> The select_frame hook is still undesirable and should be removed, but >> in the meantime this fix is seemingly an effective approximation of a >> more disciplined approach of updating the TUI screen. >> >> [ When the inferior is running while sync_execution is disabled, e.g. >> via "continue&" it looks like GDB lacks access to frame information >> thorughout -- and the hook never gets called -- so seemingly no >> worries in that case. ] >> >> [ up/down etc still work properl of course ] >> >> [ I am not sure that the change in tui_on_sync_execution_done is >> necessary/desirable. It seems normal_stop already calls >> select_frame (get_current_frame ()) after sync_execution is toggled >> off. ] >> >> gdb/ChangeLog: >> >> * tui/tui-hooks.c (tui_selected_frame_level_changed_hook): Don't >> update the screen while synchronous execution is active. >> * tui/tui-interp.c (tui_on_sync_execution_done): Make sure that >> TUI's frame information is refreshed. >> --- >> gdb/tui/tui-hooks.c | 8 ++++++++ >> gdb/tui/tui-interp.c | 5 +++++ >> 2 files changed, 13 insertions(+) >> >> diff --git a/gdb/tui/tui-hooks.c b/gdb/tui/tui-hooks.c >> index 8d84551..ca8358d 100644 >> --- a/gdb/tui/tui-hooks.c >> +++ b/gdb/tui/tui-hooks.c >> @@ -133,6 +133,14 @@ tui_selected_frame_level_changed_hook (int level) >> if (level < 0) >> return; >> >> + /* Do not respond to frame changes occurring while synchronous execution is >> + enabled. Updating the screen in response to each such frame change just >> + results in pointless flicker and slowdown. Once synchronous execution is >> + done this hook will get called again to ensure that our frame information >> + is refreshed. */ >> + if (sync_execution) >> + return; >> + >> old_chain = make_cleanup_restore_target_terminal (); >> target_terminal_ours_for_output (); >> >> diff --git a/gdb/tui/tui-interp.c b/gdb/tui/tui-interp.c >> index 1a5639d..2477536 100644 >> --- a/gdb/tui/tui-interp.c >> +++ b/gdb/tui/tui-interp.c >> @@ -107,6 +107,11 @@ tui_on_sync_execution_done (void) >> { >> if (!interp_quiet_p (tui_interp)) >> display_gdb_prompt (NULL); >> + >> + /* Make sure our frame information is refreshed now that synchronous >> + execution is done. */ >> + if (tui_active) >> + deprecated_selected_frame_level_changed_hook (0); > > This condition ought to be if (tui_active && has_stack_frames ()) so > that we don't call the hook (and thus, try to lookup frame > information) after the inferior has exited (which would result in a > confusing "No stack." error). > >> } >> >> /* Observer for the command_error notification. */ >> -- >> 2.4.4.410.g43ed522.dirty >> Ping.