From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6865 invoked by alias); 10 Sep 2011 18:47:41 -0000 Received: (qmail 6857 invoked by uid 22791); 10 Sep 2011 18:47:40 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f169.google.com (HELO mail-yx0-f169.google.com) (209.85.213.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 10 Sep 2011 18:47:26 +0000 Received: by yxi19 with SMTP id 19so1392807yxi.0 for ; Sat, 10 Sep 2011 11:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.145.10 with SMTP id o10mr19109934yhj.90.1315680445508; Sat, 10 Sep 2011 11:47:25 -0700 (PDT) Received: by 10.236.201.33 with HTTP; Sat, 10 Sep 2011 11:47:25 -0700 (PDT) In-Reply-To: <201109101751.35845.pedro@codesourcery.com> References: <201108042110.45405.pedro@codesourcery.com> <201109101751.35845.pedro@codesourcery.com> Date: Sun, 11 Sep 2011 00:46:00 -0000 Message-ID: Subject: Re: Eliminate tui_command_loop From: Matt Rice To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-09/txt/msg00178.txt.bz2 On Sat, Sep 10, 2011 at 9:51 AM, Pedro Alves wrote: > On Saturday 10 September 2011 13:46:22, Matt Rice wrote: > >> I suppose the right thing to do is add interp_set_uiout(interp, uiout) >> so tui can control whatever its current_interpreter->interpreter_out fie= ld is. > > Yeah. =A0Though I think making current_interpreter->interpreter_out a cal= lback > that returns the correct uiout instead is a bit better. =A0One place less > to store the uiout to use that way. =A0(I wonder if we can make the tui r= eturn > cli_out and friends when the TUI is off.) > good idea I think, since sending the previous email, I'm also a little worried about the inverse scenario though, that current_uiout can become out of date, when we call tui_enable/tui_disa= ble it'd seem adding something current_uiout =3D current_interpreter->procs->ui_out_proc (current_interp= reter); in start_event_loop would get us back to where tui_command_loop was when it set the current_uiout. or something like: interp_changed_ui_out(struct interp *interp) { if (interp =3D=3D current_interpreter) current_uiout =3D current_interpreter->procs->ui_out_proc (current_interpreter); } (and calling that from tui_enable/tui_disable after setting tui_active) I believe that this sort of current_uiout problem is going to be less appar= ent, e.g. if we're using the cli out and we should be using the tui one we may just get wrong behavior instead of a segfault because a) tui_out contains cli_out_impl stuff, so the behaviour may even appear correct. b) because tui_old_uiout probably won't segfault somewhere random in ncurses like tui_out does when we use the wrong one. I haven't figured out a way to cause issues this way, but haven't tried terribly hard, testsuite/gdb.base/tui-layout.exp though does appear to get a stale current_uiout because I added some a gdb_assert though i'm not sure how long/if it is long enough to cause problems. I could easily be missing something though and it's fine.