Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Matt Rice <ratmice@gmail.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Eliminate tui_command_loop
Date: Sun, 11 Sep 2011 00:46:00 -0000	[thread overview]
Message-ID: <CACTLOFptFv3ddnCEKpzNQHtE6xsQ-2WGe1fQqsRiTCEeOdZoMg@mail.gmail.com> (raw)
In-Reply-To: <201109101751.35845.pedro@codesourcery.com>

On Sat, Sep 10, 2011 at 9:51 AM, Pedro Alves <pedro@codesourcery.com> 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 field is.
>
> Yeah.  Though I think making current_interpreter->interpreter_out a callback
> that returns the correct uiout instead is a bit better.  One place less
> to store the uiout to use that way.  (I wonder if we can make the tui return
> 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_disable

it'd seem adding something
  current_uiout = current_interpreter->procs->ui_out_proc (current_interpreter);
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 == current_interpreter)
    current_uiout = 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 apparent,

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.


  reply	other threads:[~2011-09-10 18:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 20:11 Pedro Alves
2011-08-04 20:18 ` Tom Tromey
2011-08-05 13:02   ` Pedro Alves
2011-08-05 15:11     ` Tom Tromey
2011-08-04 20:39 ` Thiago Jung Bauermann
2011-08-05  3:49   ` Sergio Durigan Junior
2011-08-05 12:37   ` Pedro Alves
2011-09-10 12:51 ` Matt Rice
2011-09-10 16:52   ` Matt Rice
2011-09-10 18:47   ` Pedro Alves
2011-09-11  0:46     ` Matt Rice [this message]
2011-09-11 14:41       ` Matt Rice
2011-09-13  8:29         ` PR gdb/13175 (Re: Eliminate tui_command_loop) Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACTLOFptFv3ddnCEKpzNQHtE6xsQ-2WGe1fQqsRiTCEeOdZoMg@mail.gmail.com \
    --to=ratmice@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox