From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121724 invoked by alias); 15 Jun 2015 16:14:47 -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 121715 invoked by uid 89); 15 Jun 2015 16:14:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ob0-f170.google.com Received: from mail-ob0-f170.google.com (HELO mail-ob0-f170.google.com) (209.85.214.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 15 Jun 2015 16:14:45 +0000 Received: by obbsn1 with SMTP id sn1so67464533obb.1 for ; Mon, 15 Jun 2015 09:14:44 -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=upzvC2819MT4IhM7Z6iftEr7guQZlhWLnHQWJ1DCP7w=; b=D0mw+1tFTROt5VkFeLhlvLsVp8d094sra2B9ac8faWHqy9LCd/SIxRThhkozqt20qk I2pgvxPssdwDIzAtzOHBYmFxmXge9jNlU4RGfGRn3zNCzrkBQntjMnlMZmHiUofmAjuL CFsffJsosiaykBeNWfDIRvSWXlL9TAnINoM2lBj6LUaDwSwxGIptabnHlvCgk7kKEUd3 M11OuH4/5Iv4Rt3Lx/mxgsPYyMEOCOLqXrfE+XKu8NgtAYWUH0qiIEXtMOQIjXg6KmcO roz41//oykE4gjwha7up/KWrrckuwOR4RLpo+h633YRdT2dqnQzY65TdQE0ZbE2mtZ0Y +mCQ== X-Gm-Message-State: ALoCoQk/TcnKQrv8BU+QmZB6OGjweVXiK5GsO4vPDi7IMheuHvk+VBRWcbezRJy3O5EyWgpFXbXa X-Received: by 10.60.69.7 with SMTP id a7mr24225354oeu.14.1434384883903; Mon, 15 Jun 2015 09:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.167 with HTTP; Mon, 15 Jun 2015 09:14:23 -0700 (PDT) In-Reply-To: <557EEAB0.5040607@redhat.com> References: <1433260372-12694-1-git-send-email-patrick@parcs.ath.cx> <557EEAB0.5040607@redhat.com> From: Patrick Palka Date: Mon, 15 Jun 2015 16:14:00 -0000 Message-ID: Subject: Re: [PATCH] Call target_terminal_ours() before refreshing TUI's frame info To: Pedro Alves Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg00319.txt.bz2 On Mon, Jun 15, 2015 at 11:09 AM, Pedro Alves wrote: > On 06/02/2015 04:52 PM, Patrick Palka wrote: >> In some cases tui_show_frame_info() may get called while the inferior's >> terminal settings are still in effect. But when we call this function >> we absolutely need to have our terminal settings in effect because the >> function is responsible for redrawing TUI's windows following a change >> in the selected frame or a change in the PC. If our terminal settings >> are not in effect, the screen does not get redrawn properly, causing >> temporary display artifacts (which can be fixed via ^L). >> >> This scenario happens most prominently when stepping through a program >> in TUI while a watchpoint is in effect. >> >> Here is an example backtrace for when tui_show_frame_info() gets called >> while target_terminal_is_inferior() == 1: >> >> #1 0x00000000004988ee in tui_selected_frame_level_changed_hook (level=0) >> #2 0x0000000000617b99 in select_frame (fi=0x18c9820) >> #3 0x0000000000617c3f in get_selected_frame (message=message@entry=0x0) >> #4 0x00000000004ce534 in update_watchpoint (b=b@entry=0x2d9a760, >> reparse=reparse@entry=0) >> #5 0x00000000004d625e in insert_breakpoints () >> #6 0x0000000000531cfe in keep_going (ecs=ecs@entry=0x7ffea7884ac0) >> #7 0x00000000005326d7 in process_event_stop_test (ecs=ecs@entry=0x7ffea7884ac0) >> #8 0x000000000053596e in handle_inferior_event_1 (ecs=0x7ffea7884ac0) >> >> The fix is simple: call target_terminal_ours() before calling >> tui_show_frame_info() in TUI's frame-changed hook, making sure to >> restore the original terminal settings afterwards. >> >> gdb/ChangeLog: >> >> * tui/tui-hooks.c (tui_selected_frame_level_changed_hook): Call >> target_terminal_ours() before calling tui_show_frame_info(), and >> restore the original terminal settings afterwards. > > > OK, though please try/use target_terminal_ours_for_output instead. Okay. > > I think we should get rid of this hook entirely, and refresh > the window at some higher level point. Refreshing the window for > each internal stop and/or selected frame save/restore results in > lots of pointless flicker... I'm sure you've noticed. :-) Good idea. > > Thanks, > Pedro Alves >