From: Nick Roberts <nickrob@snap.net.nz>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, ghost@cs.msu.su
Subject: Re: [patch:MI] Observer for thread-changed
Date: Tue, 10 Jun 2008 02:30:00 -0000 [thread overview]
Message-ID: <18509.57602.879804.675918@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200806100104.28694.pedro@codesourcery.com>
> It all amounts to:
>
> - should there be an MI async event on -thread-select if the
> reply already carries that information?
But the CLI command "thread" doesn't. I think MI should try to reflect the
state of GDB and the inferior. It shouldn't really matter what commands were
used to put it in that state.
> - if a command requires a synchronous reply, then it should be
> implemented in the command itself, not in an observer.
Which commands require a synchronous reply?
> > How about the change below instead? This, of course, requires no change to
> > mi-main.c.
>
> I'd really prefer to keep gdb_thread_select just an exception
> wrapper, and do the observer call in do_captured_thread_select.
If it goes at the end of do_captured_thread_select then I guess that will be
after any exceptions but, to me, putting the logic in gdb_thread_select makes
it clearer that the thread only gets reported when there is no exception.
As libgdb seems to be dead in the water (gdb_breakpoint in breakpoint.c
has gone altogether) do we need to be so precious about these function now?
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2008-06-10 2:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 12:16 Nick Roberts
2008-06-09 13:36 ` Pedro Alves
2008-06-09 13:28 ` Pedro Alves
2008-06-09 15:06 ` Pedro Alves
2008-06-09 14:15 ` Pedro Alves
2008-06-09 23:35 ` Nick Roberts
2008-06-10 1:40 ` Pedro Alves
2008-06-10 2:30 ` Nick Roberts [this message]
2008-06-10 3:13 ` Pedro Alves
2008-06-10 6:39 ` Nick Roberts
2009-01-17 0:10 ` [PATCH]:annotations [was Re: [patch:MI] Observer for thread-changed] Nick Roberts
2009-01-17 17:54 ` [PATCH]:annotations Tom Tromey
2008-06-10 8:26 ` [patch:MI] Observer for thread-changed Vladimir Prus
2008-06-10 9:24 ` Nick Roberts
2008-06-10 10:26 ` Vladimir Prus
2008-06-10 17:23 ` Daniel Jacobowitz
2008-06-14 18:52 ` Vladimir Prus
2008-06-14 19:13 ` Tom Tromey
2008-06-14 19:22 ` Bob Rossi
2008-06-15 3:20 ` Nick Roberts
2008-06-14 20:04 ` Vladimir Prus
2008-06-15 21:51 ` Tom Tromey
2008-06-14 19:43 ` Daniel Jacobowitz
2008-06-15 0:44 ` Nick Roberts
2008-06-15 21:03 ` Vladimir Prus
2008-06-15 22:31 ` Nick Roberts
2008-06-16 22:28 ` Daniel Jacobowitz
2008-06-15 17:58 ` Vladimir Prus
2008-06-10 8:40 ` Vladimir Prus
2008-06-10 9:19 ` Nick Roberts
2008-06-10 9:36 ` Vladimir Prus
2008-06-11 0:08 ` Nick Roberts
2008-06-11 7:46 ` Eli Zaretskii
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=18509.57602.879804.675918@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=gdb-patches@sourceware.org \
--cc=ghost@cs.msu.su \
--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