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 22:19:32 +0400
- Subject: Re: MI non-stop interface details
- References: <6D19CA8D71C89C43A057926FE0D4ADAA042910AB@ecamlmw720.eamcs.ericsson.se> <200805022135.39862.vladimir@codesourcery.com> <481B5672.8080707@windriver.com>
On Friday 02 May 2008 21:59:14 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Friday 02 May 2008 21:31:08 Pawel Piech wrote:
> >
> >
> >> 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.
> >>
> >> Thank You :-) It would be more helpful if the thread-id field was
> >> left alone and always reported the triggering thread as it does now.
> >> It would be better (more consistent and logical) if the new field
> >> was used to indicate whether or not the whole container changed state.
> >>
> >
> > For avoidance of doubt, do you have any objections to *running using the "thread-id"
> > as the field name? Since this is new notification, there's no backward compatibility
> > issues, and there's no issue of which thread originally triggered anything.
> >
> > - Volodya
> >
> First of all, I think it's important to make the events in all-stop and
> non-stop mode to be consistent. Additionally, it is helpful if the
> fields, such as thread-id have consistent meaning even if they are used
> in different events. So for consistency sake it would be better to also
> use thread-id to indicate the triggering thread in the running event as
> well, and use a separate field to indicate whether the container changed
> state. BTW the triggering thread is needed in the running event, for
> example when stepping in the all-stop mode.
And what the triggering thread would report in that case? The thread where
the step command was emitted? Frontend knows it already, no?
- Volodya