This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI non-stop interface details
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Pawel Piech <pawel dot piech at windriver dot com>
- Cc: Marc Khouzam <marc dot khouzam at ericsson dot com>, Pedro Alves <pedro at codesourcery dot com>, gdb at sourceware dot org
- Date: Fri, 2 May 2008 21:13:12 +0400
- Subject: Re: MI non-stop interface details
- References: <6D19CA8D71C89C43A057926FE0D4ADAA042910AB@ecamlmw720.eamcs.ericsson.se> <200805021820.47837.vladimir@codesourcery.com> <481B4830.9040909@windriver.com>
On Friday 02 May 2008 20:58:24 Pawel Piech wrote:
> > If the thread-id field has a value of "all", then all threads are stopped,
> > but it's just a shortcut for a number of *stopped, one per each thread.
> >
> This leaves out an important piece of information: the triggering
> thread,
Ah, I mostly had *running in mind, that does not have any triggering thread.
> which is used by the IDE to decide which thread should get the
> focus. You may not see a use case for it now, but sooner or later you
> will add an option to the breakpoint to stop all threads in non-stop
> mode and you'll want to tell the client which thread hit the breakpoint.
Right now, *stopped reports the thread which hit the breakpoint. In
all-stop mode, all threads are stopped. In non-stop mode, only that thread
is stopped.
We surely can add an extra field to indicate which threads are actually stopped,
if this makes life easier.
> >> I see no reason to create a separate name space and in fact adding
> >> another name space just requires more logic to maintain it. thread-id
> >> is just a handle that is obtained through well-documented commands, the
> >> MI clients are not likely to get confused by the fact that containers
> >> and threads are in the same namespace. Additionally, if GDB was ever to
> >> support more hierarchical systems: such as
> >> target->core->processes->threads, it will have to keep revising the
> >> protocol (in incompatibility inducing ways) to keep up. But I guess
> >> you'd have to believe that this is a real issue first.
> >>
> >
> > I think the MI commands to query the hierarchy of "containers" will be fairly
> > agnostic of the actual meaning of each containers (just like variable objects
> > allow to describe arbitrary structure). That said, I'm not 100% that
> > making the namespace of containers and namespace of thread IDs is not going
> > to upset existing frontends.
> >
> > - Volodya
> >
> Can you think of a scenario in a client which would break? Would
> KDevelop break?
I cannot create a concrete use-case where a client will break, yet.
> Maybe implementers of other client can speak up on this.
If they read this list :-(
- Volodya