MI non-stop interface details

MI non-stop interface details

[Vladimir Prus]

[Marc, Pawel, I CC you since you were involved in the original
discussions about MI interface for non-stop mode].

Some time ago I've posted a spec for MI interface in non-stop mode.
The discussion (and subsequent implementation) revealed a couple of
details that I'd like to finally settle.

Thread specification
--------------------

With non-stop mode, we have a possible race condition due to GDB notion
of current thread. GDB both uses the current thread to decide on which
thread the operation like 'step' should work, and it switches the current
thread when a stop event in a thread is detected. As the result, if a frontend
emits a command assuming that that current thread is N, and stop even is detected
before that command is executed, it will execute in the wrong thread.

The current non-stop patches introduce a --thread option to pretty much
every MI command, that make MI operate on the specified thread. I think
this is the best interface, and will document it as such in the MI docs.

At the same time, a suggestion was made to stop GDB to switch the (user-visible)
current thread. This will have two advantages:

  - CLI users won't see the thread switches
  - Some existing frontends are more easily adjusted to this interface. 
  In particular, Eclipse DSF-GDB does not have a central place where
  the --thread option can be conveniently added.

Pedro Alves has written a patch that disables the current thread switch, so
this approach is in fact possible. I think this leaves us with the following
scheme:

- In non-stop mode, the current thread is not automatically switched on
stops
- All MI commands will get the --thread option, as that allows the frontend
not to bother with keeping track of the current thread. This option will
be recommended in the manual
- Frontend authors that know what they are doing can ignore the --thread
option. (They will have to explicitly emit -thread-select, presumably immediately
after seeing the *stopped notification).

There are a couple of open questions.

1. Presently, -exec-continue resumes all threads, and the current thread
has no effect. I think it's desirable to be able to resume a single thread,
and for that, we actually need the --thread option for -exec-continue, to
mean that a single thread must be resumed.
2. Presently, -exec-step also resumes all threads. There's an option,
"scheduler-locking" that can be used for cause -exec-step to resume only
the current thread. It seems to be, that for non-stop mode, resuming all
threads is a wrong thing to do, therefore -exec-step, when in non-stop
mode, will resume only the thread been stepped. This will be the same
no matter if the thread is specified implicitly or explicitly.

Inferior function calls
-----------------------

We already have the *stopped async event, and I have a patch to introduce the
*running async event. Those are not emitted when doing inferiour function calls,
since doing so may cause a frontend to infinitely refresh its state. I propose
the following mechanism to enable those notifications for frontends that
are sufficiently robust:

1. Declare that MI might have some features that are not enabled by default.
2. Introduce new command -enable-feature, which takes a name of feature and enables
it. 
3. Make up a name of a feature, say inferior_call_notifications, and add that
feature to the output of -list-features.
4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
for inferiour function calls.

Any comments?

- Volodya

Re: MI non-stop interface details

[Doug Evans]

On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
<vladimir@codesourcery.com> wrote:
>  At the same time, a suggestion was made to stop GDB to switch the (user-visible)
>  current thread. This will have two advantages:
>
>   - CLI users won't see the thread switches

IOW GDB won't switch the current thread on the user, right?  [just
want to understand what you're saying, not to suggest a preference,
per se]

>  There are a couple of open questions.
>
>  1. Presently, -exec-continue resumes all threads, and the current thread
>  has no effect. I think it's desirable to be able to resume a single thread,
>  and for that, we actually need the --thread option for -exec-continue, to
>  mean that a single thread must be resumed.
>  2. Presently, -exec-step also resumes all threads. There's an option,
>  "scheduler-locking" that can be used for cause -exec-step to resume only
>  the current thread. It seems to be, that for non-stop mode, resuming all
>  threads is a wrong thing to do, therefore -exec-step, when in non-stop
>  mode, will resume only the thread been stepped. This will be the same
>  no matter if the thread is specified implicitly or explicitly.

Scheduler-locking has two modes, "on" and "step".  In case 1 above,
resuming just a single thread should already work if scheduler-locking
== "on" (IIUC).  Having said that, specifying the request in a
parameter to -exec-* is probably a better way to go.

IWBN if there was a way to have selective control of which threads run
(e.g. threads 3,5,7 stay stopped when execution resumes).
[controlling this in a parameter to -exec-*, as opposed to global
state, won't necessarily scale though]

>  Inferior function calls
>  -----------------------
>
>  We already have the *stopped async event, and I have a patch to introduce the
>  *running async event. Those are not emitted when doing inferiour function calls,
>  since doing so may cause a frontend to infinitely refresh its state. I propose
>  the following mechanism to enable those notifications for frontends that
>  are sufficiently robust:
>
>  1. Declare that MI might have some features that are not enabled by default.
>  2. Introduce new command -enable-feature, which takes a name of feature and enables
>  it.
>  3. Make up a name of a feature, say inferior_call_notifications, and add that
>  feature to the output of -list-features.
>  4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
>  for inferiour function calls.

5. Introduce new command -query-feature   (?) [assuming it's not there
already, I don't know]

Re: MI non-stop interface details

[Vladimir Prus]

On Saturday 26 April 2008 20:21:38 Doug Evans wrote:
> On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
> <vladimir@codesourcery.com> wrote:
> >  At the same time, a suggestion was made to stop GDB to switch the (user-visible)
> >  current thread. This will have two advantages:
> >
> >   - CLI users won't see the thread switches
> 
> IOW GDB won't switch the current thread on the user, right?  [just
> want to understand what you're saying, not to suggest a preference,
> per se]

Yes. GDB will switch its internal "current thread" when processing event,
but it will switch it back to whatever user has last set before processing
next user command.

> >  There are a couple of open questions.
> >
> >  1. Presently, -exec-continue resumes all threads, and the current thread
> >  has no effect. I think it's desirable to be able to resume a single thread,
> >  and for that, we actually need the --thread option for -exec-continue, to
> >  mean that a single thread must be resumed.
> >  2. Presently, -exec-step also resumes all threads. There's an option,
> >  "scheduler-locking" that can be used for cause -exec-step to resume only
> >  the current thread. It seems to be, that for non-stop mode, resuming all
> >  threads is a wrong thing to do, therefore -exec-step, when in non-stop
> >  mode, will resume only the thread been stepped. This will be the same
> >  no matter if the thread is specified implicitly or explicitly.
> 
> Scheduler-locking has two modes, "on" and "step".  In case 1 above,
> resuming just a single thread should already work if scheduler-locking
> == "on" (IIUC).  

Yes. The question is -- does scheduler locking "off" make any kind of 
sense in non-stop mode. If not, we should not support it.

> Having said that, specifying the request in a 
> parameter to -exec-* is probably a better way to go.
> 
> IWBN if there was a way to have selective control of which threads run
> (e.g. threads 3,5,7 stay stopped when execution resumes).
> [controlling this in a parameter to -exec-*, as opposed to global
> state, won't necessarily scale though]

There is none, at the moment. I believe Nick has proposed some ways how
this can be done, but there was not a demand for that yet. Maybe they will,
when folks start using non-stop mode.

> 
> >  Inferior function calls
> >  -----------------------
> >
> >  We already have the *stopped async event, and I have a patch to introduce the
> >  *running async event. Those are not emitted when doing inferiour function calls,
> >  since doing so may cause a frontend to infinitely refresh its state. I propose
> >  the following mechanism to enable those notifications for frontends that
> >  are sufficiently robust:
> >
> >  1. Declare that MI might have some features that are not enabled by default.
> >  2. Introduce new command -enable-feature, which takes a name of feature and enables
> >  it.
> >  3. Make up a name of a feature, say inferior_call_notifications, and add that
> >  feature to the output of -list-features.
> >  4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
> >  for inferiour function calls.
> 
> 5. Introduce new command -query-feature   (?) [assuming it's not there
> already, I don't know]

That will report if a feature is enabled or not? We don't have it (just like we don't have
-enable-feature yet). I'm thinking, though, that for all features we'd document if it's
enabled by default, or not, so this command might not be a big use.

- Volodya

RE: MI non-stop interface details

[Marc Khouzam]

> >   - CLI users won't see the thread switches
> > 
> > IOW GDB won't switch the current thread on the user, right?  [just
> > want to understand what you're saying, not to suggest a preference,
> > per se]
> 
> Yes. GDB will switch its internal "current thread" when processing event,
> but it will switch it back to whatever user has last set before processing
> next user command.

I think this is great.

> > 5. Introduce new command -query-feature   (?) [assuming it's not there
> > already, I don't know]
>
> That will report if a feature is enabled or not? We don't have it (just like 
> we don't have -enable-feature yet). I'm thinking, though, that for all features 
> we'd document if it's enabled by default, or not, so this command might not be 
> a big use.

You may be right that such a command may not prove very useful, but in my experience,
if you can modify a setting, it is always good to have a way to report its current state.

Re: MI non-stop interface details

[Pedro Alves]

A Saturday 26 April 2008 16:39:36, Vladimir Prus wrote:
> [Marc, Pawel, I CC you since you were involved in the original
> discussions about MI interface for non-stop mode].
>
> Some time ago I've posted a spec for MI interface in non-stop mode.
> The discussion (and subsequent implementation) revealed a couple of
> details that I'd like to finally settle.
>
> Thread specification
> --------------------
>
> With non-stop mode, we have a possible race condition due to GDB notion
> of current thread. GDB both uses the current thread to decide on which
> thread the operation like 'step' should work, and it switches the current
> thread when a stop event in a thread is detected. As the result, if a
> frontend emits a command assuming that that current thread is N, and stop
> even is detected before that command is executed, it will execute in the
> wrong thread.
>
> The current non-stop patches introduce a --thread option to pretty much
> every MI command, that make MI operate on the specified thread. I think
> this is the best interface, and will document it as such in the MI docs.
>
> At the same time, a suggestion was made to stop GDB to switch the
> (user-visible) current thread. This will have two advantages:
>
>   - CLI users won't see the thread switches
>   - Some existing frontends are more easily adjusted to this interface.
>   In particular, Eclipse DSF-GDB does not have a central place where
>   the --thread option can be conveniently added.
>
> Pedro Alves has written a patch that disables the current thread switch, so
> this approach is in fact possible. I think this leaves us with the
> following scheme:
>
> - In non-stop mode, the current thread is not automatically switched on
> stops
> - All MI commands will get the --thread option, as that allows the frontend
> not to bother with keeping track of the current thread. This option will
> be recommended in the manual

If we get rid of the auto thread switching, then GDB's current thread
will always be the thread the frontend considers current too, because
it was the frontend that made it the current thread.  What is this
"keeping track" you mention that would be needed for frontends
not using --thread?

Also, does --thread switch the current thread permanently as if 
-thread-select was used, or does it only change it for the
processing of the command?  That is, should GDB revert to the selected
thread after processing an -exec-* --thread command?

> - Frontend authors that know what they are doing can ignore the --thread
> option. (They will have to explicitly emit -thread-select, presumably
> immediately after seeing the *stopped notification).
>

Not immediatelly.  The *stopped notification will once per thread that
reports a stop.  The frontend would use it to update its internal state 
representing the thread (change the thread icon to a "-like paused icon
for instance).  The frontend would send -thread-select when the user
activelly clicks on another thread icon (or equivalent action).
It doesn't seem much different from switching the internal-to-the-frontend 
notion of current thread, from which the --thread=$id parameter is built.

> There are a couple of open questions.
>
> 1. Presently, -exec-continue resumes all threads, and the current thread
> has no effect. I think it's desirable to be able to resume a single thread,
> and for that, we actually need the --thread option for -exec-continue, to
> mean that a single thread must be resumed.
> 2. Presently, -exec-step also resumes all threads. There's an option,
> "scheduler-locking" that can be used for cause -exec-step to resume only
> the current thread. It seems to be, that for non-stop mode, resuming all
> threads is a wrong thing to do, therefore -exec-step, when in non-stop
> mode, will resume only the thread been stepped. This will be the same
> no matter if the thread is specified implicitly or explicitly.
>

Can we make -exec-continue/-exec-step/-exec-next consistent, by
making the case of not passing a --thread parameter semantics
match?  Given the same arguments, if one resumes just one thread,
the others should too, IMHO.

If we choose to always ignore the scheduler-locking setting
in non-stop mode, by making them operate on the current thread
only, we can still honour '-exec-continue --thread="all"', 
or '-exec-step --all'.  If people find it desirable, we can
make "scheduler-locking off" with no --thread specified mean resume
all threads.  That I tend to agree is wrong in non-stop mode.  I'd
rather have two buttons on the IDE -- "resume" and "resume all",
(or two keyboard shortcuts, etc.) then to export the sheduler-locking
modes to the user interface.

-- 
Pedro Alves

Re: MI non-stop interface details

[Vladimir Prus]

On Sunday 27 April 2008 23:17:02 Pedro Alves wrote:
> A Saturday 26 April 2008 16:39:36, Vladimir Prus wrote:
> > [Marc, Pawel, I CC you since you were involved in the original
> > discussions about MI interface for non-stop mode].
> >
> > Some time ago I've posted a spec for MI interface in non-stop mode.
> > The discussion (and subsequent implementation) revealed a couple of
> > details that I'd like to finally settle.
> >
> > Thread specification
> > --------------------
> >
> > With non-stop mode, we have a possible race condition due to GDB notion
> > of current thread. GDB both uses the current thread to decide on which
> > thread the operation like 'step' should work, and it switches the current
> > thread when a stop event in a thread is detected. As the result, if a
> > frontend emits a command assuming that that current thread is N, and stop
> > even is detected before that command is executed, it will execute in the
> > wrong thread.
> >
> > The current non-stop patches introduce a --thread option to pretty much
> > every MI command, that make MI operate on the specified thread. I think
> > this is the best interface, and will document it as such in the MI docs.
> >
> > At the same time, a suggestion was made to stop GDB to switch the
> > (user-visible) current thread. This will have two advantages:
> >
> >   - CLI users won't see the thread switches
> >   - Some existing frontends are more easily adjusted to this interface.
> >   In particular, Eclipse DSF-GDB does not have a central place where
> >   the --thread option can be conveniently added.
> >
> > Pedro Alves has written a patch that disables the current thread switch, so
> > this approach is in fact possible. I think this leaves us with the
> > following scheme:
> >
> > - In non-stop mode, the current thread is not automatically switched on
> > stops
> > - All MI commands will get the --thread option, as that allows the frontend
> > not to bother with keeping track of the current thread. This option will
> > be recommended in the manual
> 
> If we get rid of the auto thread switching, then GDB's current thread
> will always be the thread the frontend considers current too, because
> it was the frontend that made it the current thread.  What is this
> "keeping track" you mention that would be needed for frontends
> not using --thread?

Suppose that for whatever reason, frontend would like to do anything
in a thread that is not explicitly selected by a user. Then, frontend gets
to switch to that thread, do something, and switch back, and should take
care that no other operation is done while we've temporary switched threads.

> Also, does --thread switch the current thread permanently as if 
> -thread-select was used, or does it only change it for the
> processing of the command?  That is, should GDB revert to the selected
> thread after processing an -exec-* --thread command?

Right now, --thread switches the thread permanently. Which is quite fine
if frontend always adds --thread.

> > - Frontend authors that know what they are doing can ignore the --thread
> > option. (They will have to explicitly emit -thread-select, presumably
> > immediately after seeing the *stopped notification).
> >
> 
> Not immediatelly.  The *stopped notification will once per thread that
> reports a stop.  The frontend would use it to update its internal state 
> representing the thread (change the thread icon to a "-like paused icon
> for instance).  The frontend would send -thread-select when the user
> activelly clicks on another thread icon (or equivalent action).

Of course, a frontend that, in response to *stopped, will do nothing but
marking a thread as stopped, will be fairly unpopular :-) Usually, you
want to show the variables at the stop point, so you'd switch to the stop
thread.

> It doesn't seem much different from switching the internal-to-the-frontend 
> notion of current thread, from which the --thread=$id parameter is built.
> 
> > There are a couple of open questions.
> >
> > 1. Presently, -exec-continue resumes all threads, and the current thread
> > has no effect. I think it's desirable to be able to resume a single thread,
> > and for that, we actually need the --thread option for -exec-continue, to
> > mean that a single thread must be resumed.
> > 2. Presently, -exec-step also resumes all threads. There's an option,
> > "scheduler-locking" that can be used for cause -exec-step to resume only
> > the current thread. It seems to be, that for non-stop mode, resuming all
> > threads is a wrong thing to do, therefore -exec-step, when in non-stop
> > mode, will resume only the thread been stepped. This will be the same
> > no matter if the thread is specified implicitly or explicitly.
> >
> 
> Can we make -exec-continue/-exec-step/-exec-next consistent, by
> making the case of not passing a --thread parameter semantics
> match?  Given the same arguments, if one resumes just one thread,
> the others should too, IMHO.

Too late. -exec-continue resumes everything. -exec-step, from user 
standpoint, resumes one -- most users don't even know that step
can resume all threads.

> If we choose to always ignore the scheduler-locking setting
> in non-stop mode, by making them operate on the current thread
> only, we can still honour '-exec-continue --thread="all"', 
> or '-exec-step --all'.  If people find it desirable, we can
> make "scheduler-locking off" with no --thread specified mean resume
> all threads.  That I tend to agree is wrong in non-stop mode.  I'd
> rather have two buttons on the IDE -- "resume" and "resume all",
> (or two keyboard shortcuts, etc.) then to export the sheduler-locking
> modes to the user interface.

I guess we can redefine the behaviour of -exec-continue in non-stop, or
in MI3, but I worry that two different behaviours will make life too
hard for frontends (and for us)

- Volodya

 

Re: MI non-stop interface details

[Pedro Alves]

A Tuesday 29 April 2008 18:04:57, Vladimir Prus wrote:

> > If we get rid of the auto thread switching, then GDB's current thread
> > will always be the thread the frontend considers current too, because
> > it was the frontend that made it the current thread.  What is this
> > "keeping track" you mention that would be needed for frontends
> > not using --thread?
>
> Suppose that for whatever reason, frontend would like to do anything
> in a thread that is not explicitly selected by a user. Then, frontend gets
> to switch to that thread, do something, and switch back, and should take
> care that no other operation is done while we've temporary switched
> threads.
>

I can't see how is it different -- in the frontend's perspective --
of keeping track of what to pass to --thread= *provided GDB doesn't switch 
threads automatically*.  But then again, I'm no frontend writer.

> > Also, does --thread switch the current thread permanently as if
> > -thread-select was used, or does it only change it for the
> > processing of the command?  That is, should GDB revert to the selected
> > thread after processing an -exec-* --thread command?
>
> Right now, --thread switches the thread permanently. Which is quite fine
> if frontend always adds --thread.
>

I'd have thought it made more sense not to, as that would enable
introducing gradually "--threads" commands in the frontend without
worrying about reverting to the previous thread, but OTOH,
it reduces the amount of switching on the GDB side, and limits the
number of reads from the inferior (read stop pc, for instance)
with the current code base.

> > Not immediatelly.  The *stopped notification will once per thread that
> > reports a stop.  The frontend would use it to update its internal state
> > representing the thread (change the thread icon to a "-like paused icon
> > for instance).  The frontend would send -thread-select when the user
> > activelly clicks on another thread icon (or equivalent action).
>
> Of course, a frontend that, in response to *stopped, will do nothing but
> marking a thread as stopped, will be fairly unpopular :-) Usually, you
> want to show the variables at the stop point, so you'd switch to the stop
> thread.
>

Fair enough. :-)  I realized that after posting.

> > It doesn't seem much different from switching the
> > internal-to-the-frontend notion of current thread, from which the
> > --thread=$id parameter is built.
> >
> > > There are a couple of open questions.
> > >
> > > 1. Presently, -exec-continue resumes all threads, and the current
> > > thread has no effect. I think it's desirable to be able to resume a
> > > single thread, and for that, we actually need the --thread option for
> > > -exec-continue, to mean that a single thread must be resumed.
> > > 2. Presently, -exec-step also resumes all threads. There's an option,
> > > "scheduler-locking" that can be used for cause -exec-step to resume
> > > only the current thread. It seems to be, that for non-stop mode,
> > > resuming all threads is a wrong thing to do, therefore -exec-step, when
> > > in non-stop mode, will resume only the thread been stepped. This will
> > > be the same no matter if the thread is specified implicitly or
> > > explicitly.
> >
> > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > making the case of not passing a --thread parameter semantics
> > match?  Given the same arguments, if one resumes just one thread,
> > the others should too, IMHO.
>
> Too late. -exec-continue resumes everything. -exec-step, from user
> standpoint, resumes one -- most users don't even know that step
> can resume all threads.
>

Oh, I'm talking non-stop mode.  It's not too late for that.

I played a bit with eclipse/java debugging (which implements non-stop),
and noticed it only resumes one thread when one clicks the
equivalent of "continue".  I have used eclipse/java heavilly in the
past, and I never found that unintuitive.  I remember
looking for a "continue all" button and not finding one, but normally
I didn't even thing about it.  Resuming one thread was just fine.

(I keep thinking that in non-stop mode, the exec commands without
--thread are equivalent to the CLI commands in non-stop mode.

I keep forgetting to pass --thread to continue& and end up
resuming more than I wanted.)

> > If we choose to always ignore the scheduler-locking setting
> > in non-stop mode, by making them operate on the current thread
> > only, we can still honour '-exec-continue --thread="all"',
> > or '-exec-step --all'.  If people find it desirable, we can
> > make "scheduler-locking off" with no --thread specified mean resume
> > all threads.  That I tend to agree is wrong in non-stop mode.  I'd
> > rather have two buttons on the IDE -- "resume" and "resume all",
> > (or two keyboard shortcuts, etc.) then to export the sheduler-locking
> > modes to the user interface.
>
> I guess we can redefine the behaviour of -exec-continue in non-stop, or
> in MI3, but I worry that two different behaviours will make life too
> hard for frontends (and for us)
>

Oh, I was talking non-stop.

-- 
Pedro Alves

Re: MI non-stop interface details

[Pawel Piech]

Pedro Alves wrote:
> I can't see how is it different -- in the frontend's perspective --
> of keeping track of what to pass to --thread= *provided GDB doesn't switch 
> threads automatically*.  But then again, I'm no frontend writer.
>   

Using -thread-select makes it easier for the front end to be compatible 
with older versions of GDB. 
Cheers,
Pawel

Re: MI non-stop interface details

[Vladimir Prus]

On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
> Pedro Alves wrote:
> > I can't see how is it different -- in the frontend's perspective --
> > of keeping track of what to pass to --thread= *provided GDB doesn't switch 
> > threads automatically*.  But then again, I'm no frontend writer.
> >   
> 
> Using -thread-select makes it easier for the front end to be compatible 
> with older versions of GDB.

Hmm, I though that only reason that -thread-select is simpler is because
in DSF, specifically, there's no central place where commands are send
and where --thread can be conveniently added. I'm not saying this is good,
or bad, but this is not the case for all frontend. Am I wrong?

- Volodya

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>   
>> Pedro Alves wrote:
>>     
>>> I can't see how is it different -- in the frontend's perspective --
>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch 
>>> threads automatically*.  But then again, I'm no frontend writer.
>>>   
>>>       
>> Using -thread-select makes it easier for the front end to be compatible 
>> with older versions of GDB.
>>     
>
> Hmm, I though that only reason that -thread-select is simpler is because
> in DSF, specifically, there's no central place where commands are send
> and where --thread can be conveniently added. I'm not saying this is good,
> or bad, but this is not the case for all frontend. Am I wrong?
>
> - Volodya
>   
In DSF-GDB there _is_ a central place where commands are sent, this is 
where the protocol state is adjusted using -thread-select.  However, the 
--thread option is being added to many but not all commands, so the same 
mechanism that adds the -thread-select could not be reused to add 
--thread option.  Instead each command which accepts --thread that would 
need to be adjusted to use the --thread, but only when in non-stop 
debugging mode.

-Pawel

Re: MI non-stop interface details

[Vladimir Prus]

Pawel Piech wrote:

> Vladimir Prus wrote:
>> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>>   
>>> Pedro Alves wrote:
>>>     
>>>> I can't see how is it different -- in the frontend's perspective --
>>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch
>>>> threads automatically*.  But then again, I'm no frontend writer.
>>>>   
>>>>       
>>> Using -thread-select makes it easier for the front end to be compatible
>>> with older versions of GDB.
>>>     
>>
>> Hmm, I though that only reason that -thread-select is simpler is because
>> in DSF, specifically, there's no central place where commands are send
>> and where --thread can be conveniently added. I'm not saying this is good,
>> or bad, but this is not the case for all frontend. Am I wrong?
>>
>> - Volodya
>>   
> In DSF-GDB there _is_ a central place where commands are sent, this is
> where the protocol state is adjusted using -thread-select.  However, the
> --thread option is being added to many but not all commands, so the same
> mechanism that adds the -thread-select could not be reused to add
> --thread option.  Instead each command which accepts --thread that would
> need to be adjusted to use the --thread, but only when in non-stop
> debugging mode.

This is not actually. The plan is for eery command will accept --thread.  
Those that don't have any use of it will ignore it. The only command,
at the moment, for which the meaning of --thread is not yet clear, and for
which the frontend might have to have custom decision logic, is --exec-continue.

- Volodya

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> Vladimir Prus wrote:
>>     
>>> On Tuesday 29 April 2008 22:03:20 Pawel Piech wrote:
>>>   
>>>       
>>>> Pedro Alves wrote:
>>>>     
>>>>         
>>>>> I can't see how is it different -- in the frontend's perspective --
>>>>> of keeping track of what to pass to --thread= *provided GDB doesn't switch
>>>>> threads automatically*.  But then again, I'm no frontend writer.
>>>>>   
>>>>>       
>>>>>           
>>>> Using -thread-select makes it easier for the front end to be compatible
>>>> with older versions of GDB.
>>>>     
>>>>         
>>> Hmm, I though that only reason that -thread-select is simpler is because
>>> in DSF, specifically, there's no central place where commands are send
>>> and where --thread can be conveniently added. I'm not saying this is good,
>>> or bad, but this is not the case for all frontend. Am I wrong?
>>>
>>> - Volodya
>>>   
>>>       
>> In DSF-GDB there _is_ a central place where commands are sent, this is
>> where the protocol state is adjusted using -thread-select.  However, the
>> --thread option is being added to many but not all commands, so the same
>> mechanism that adds the -thread-select could not be reused to add
>> --thread option.  Instead each command which accepts --thread that would
>> need to be adjusted to use the --thread, but only when in non-stop
>> debugging mode.
>>     
>
> This is not actually. The plan is for eery command will accept --thread.  
> Those that don't have any use of it will ignore it. The only command,
> at the moment, for which the meaning of --thread is not yet clear, and for
> which the frontend might have to have custom decision logic, is --exec-continue.
>
> - Volodya
>   
That's helpful.  Unfortunately UI clients that want to have a wide user 
base still need to worry about old GDB versions which do not support 
-thread, and that was my first point in this thread.  As I've seen on 
this mailing list there are users out there still on GDB 5.x.  I expect 
it will take several years before support for GDB 6.8 and prior is not 
so important.

-Pawel

Re: MI non-stop interface details

[Vladimir Prus]

On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:
      
> > In DSF-GDB there _is_ a central place where commands are sent, this is
> > where the protocol state is adjusted using -thread-select.  However, the
> > --thread option is being added to many but not all commands, so the same
> > mechanism that adds the -thread-select could not be reused to add
> > --thread option.  Instead each command which accepts --thread that would
> > need to be adjusted to use the --thread, but only when in non-stop
> > debugging mode.
>     
> 
> This is not actually. The plan is for eery command will accept --thread.  
> Those that don't have any use of it will ignore it. The only command,
> at the moment, for which the meaning of --thread is not yet clear, and for
> which the frontend might have to have custom decision logic, is --exec-continue.
> 
> - Volodya
>   
>  That's helpful.  Unfortunately UI clients that want to have a wide user base still 
>  need to worry about old GDB versions which do not support -thread, and that was my 
>  first point in this thread.  As I've seen on this mailing list there are users out 
>  there still on GDB 5.x.  I expect it will take several 
>  years before support for GDB 6.8 and prior is not so important.    

And where's the issue? On startup, issue -list-features. If you get error, this is old
GDB. If the output of -list-features does not include "thread-option", this version of
GDB does not support --thread (and don't not support non-stop, either). Then, you
can make appropriate runtime decisions. It seems better to me to make such global
decision right after starting GDB, rather than guessing things from output of *stopped,
and other indirect mechanisms.

[Note that "thread-option" is not yet produced by -list-features, because the support
for --thread is not yet in FSF tree]

- Volodya

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:
>       
>   
>>> In DSF-GDB there _is_ a central place where commands are sent, this is
>>> where the protocol state is adjusted using -thread-select.  However, the
>>> --thread option is being added to many but not all commands, so the same
>>> mechanism that adds the -thread-select could not be reused to add
>>> --thread option.  Instead each command which accepts --thread that would
>>> need to be adjusted to use the --thread, but only when in non-stop
>>> debugging mode.
>>>       
>>     
>>
>> This is not actually. The plan is for eery command will accept --thread.  
>> Those that don't have any use of it will ignore it. The only command,
>> at the moment, for which the meaning of --thread is not yet clear, and for
>> which the frontend might have to have custom decision logic, is --exec-continue.
>>
>> - Volodya
>>   
>>  That's helpful.  Unfortunately UI clients that want to have a wide user base still 
>>  need to worry about old GDB versions which do not support -thread, and that was my 
>>  first point in this thread.  As I've seen on this mailing list there are users out 
>>  there still on GDB 5.x.  I expect it will take several 
>>  years before support for GDB 6.8 and prior is not so important.    
>>     
>
> And where's the issue? On startup, issue -list-features. If you get error, this is old
> GDB. If the output of -list-features does not include "thread-option", this version of
> GDB does not support --thread (and don't not support non-stop, either). Then, you
> can make appropriate runtime decisions. It seems better to me to make such global
> decision right after starting GDB, rather than guessing things from output of *stopped,
> and other indirect mechanisms.
>
>   
> [Note that "thread-option" is not yet produced by -list-features, because the support
> for --thread is not yet in FSF tree]
>
> - Volodya
>   
I disagree.  I think it is more direct to place the logic of deciphering 
the meaning of the event with the code that handles that event.  If 
there are optional fields in the event, they can be interpreted if 
present and interpreted another way if not present, but the logic is 
very localized.
Using -list-features to determine what the protocol behavior is, forces 
the client to scatter logic about how to interpret events and use 
commands.  The code that launches and configures GDB is typically in a 
different component than the code that interprets events and sends 
individual commands.  In other words, the problem with using 
-list-features to determine the protocol behavior is that it makes it 
more difficult for the client to keep its code modular. 

(warning: soap box speach coming)
I have to admit though that history is on your side.  Through its many 
versions GDB has freely changed (or "cleaned up") the MI protocol in 
subtle ways without warning (e.g. adding quotes around the condition 
parameter in -break-condition).  This creates headaches for clients, and 
can ultimately make the client code difficult to maintain. A perfect 
example of this is the CDI-GDB Eclipse integration.  While it has other 
architectural issues, the myriad of workarounds for various GDB versions 
in it makes it difficult to know whether a change for latest GDB version 
won't break support for old GDB versions.  What I don't think GDB 
maintainers realize is that ultimately this policy does a lot of harm to 
GDB adoption and GDB's reputation in the larger community.  I would 
guess that most users of GDB have some kind of graphical interface and 
their quality is linked to perception of quality of GDB.   GDB/MI is a 
published protocol with many users, and I wish that this fact had more 
significance to its maintainers.

Cheers,
Pawel

Re: MI non-stop interface details

[Vladimir Prus]

On Thursday 01 May 2008 21:52:00 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Thursday 01 May 2008 20:50:28 Pawel Piech wrote:
> >       
> >   
> >>> In DSF-GDB there _is_ a central place where commands are sent, this is
> >>> where the protocol state is adjusted using -thread-select.  However, the
> >>> --thread option is being added to many but not all commands, so the same
> >>> mechanism that adds the -thread-select could not be reused to add
> >>> --thread option.  Instead each command which accepts --thread that would
> >>> need to be adjusted to use the --thread, but only when in non-stop
> >>> debugging mode.
> >>>       
> >>     
> >>
> >> This is not actually. The plan is for eery command will accept --thread.  
> >> Those that don't have any use of it will ignore it. The only command,
> >> at the moment, for which the meaning of --thread is not yet clear, and for
> >> which the frontend might have to have custom decision logic, is --exec-continue.
> >>
> >> - Volodya
> >>   
> >>  That's helpful.  Unfortunately UI clients that want to have a wide user base still 
> >>  need to worry about old GDB versions which do not support -thread, and that was my 
> >>  first point in this thread.  As I've seen on this mailing list there are users out 
> >>  there still on GDB 5.x.  I expect it will take several 
> >>  years before support for GDB 6.8 and prior is not so important.    
> >>     
> >
> > And where's the issue? On startup, issue -list-features. If you get error, this is old
> > GDB. If the output of -list-features does not include "thread-option", this version of
> > GDB does not support --thread (and don't not support non-stop, either). Then, you
> > can make appropriate runtime decisions. It seems better to me to make such global
> > decision right after starting GDB, rather than guessing things from output of *stopped,
> > and other indirect mechanisms.
> >
> >   
> > [Note that "thread-option" is not yet produced by -list-features, because the support
> > for --thread is not yet in FSF tree]
> >
> > - Volodya
> >   
> I disagree.  I think it is more direct to place the logic of deciphering 
> the meaning of the event with the code that handles that event.  If 
> there are optional fields in the event, they can be interpreted if 
> present and interpreted another way if not present, but the logic is 
> very localized.
> Using -list-features to determine what the protocol behavior is, forces 
> the client to scatter logic about how to interpret events and use 
> commands.  The code that launches and configures GDB is typically in a 
> different component than the code that interprets events and sends 
> individual commands.  In other words, the problem with using 
> -list-features to determine the protocol behavior is that it makes it 
> more difficult for the client to keep its code modular. 

I guess I have different opinion on modularity -- it's quite possible
for the startup code to inform each inidividual module how it should
behave. Given that traditionally, MI often omits a field if it has
some "default" value, I'm sure you'll run into cases where you don't know
where absence of a field means that GDB is too old, or GDB has a bug,
or the field has a default values, etc.

> (warning: soap box speach coming)
> I have to admit though that history is on your side.  Through its many 
> versions GDB has freely changed (or "cleaned up") the MI protocol in 
> subtle ways without warning (e.g. adding quotes around the condition 
> parameter in -break-condition).  This creates headaches for clients, and  
> can ultimately make the client code difficult to maintain. A perfect 
> example of this is the CDI-GDB Eclipse integration.  While it has other 
> architectural issues, the myriad of workarounds for various GDB versions 
> in it makes it difficult to know whether a change for latest GDB version 
> won't break support for old GDB versions.  What I don't think GDB 
> maintainers realize is that ultimately this policy does a lot of harm to 
> GDB adoption and GDB's reputation in the larger community.  I would 
> guess that most users of GDB have some kind of graphical interface and 
> their quality is linked to perception of quality of GDB.   GDB/MI is a 
> published protocol with many users, and I wish that this fact had more 
> significance to its maintainers.

GDB/MI is actually not a finished published protocol -- it's work in progress. 
Unfortunately, frontend maintainers tended to read between the lines, and guess
the behaviour and accepted input instead of asking here. And in cases where what
they've read between the lines does not correspond to what GDB developers means,
the result is a buggy frontend :-)

Given that MI, presently, is still not adequate for such basic tasks as 
listing local variables in a  function, it will change, and it might break 
things, and frontend developers should provide the input to avoid surprises.
You and Marc represent Eclipse here, and Nick represent Emacs, and 
I represent KDevelop, so those three are fine, but other frontend developers
should be more active here.

Probably, I should add big warning to MI manual, saying that everything that is not
100% clear must be asked on the list.

- Volodya

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> GDB/MI is actually not a finished published protocol -- it's work in progress. 
> Unfortunately, frontend maintainers tended to read between the lines, and guess
> the behaviour and accepted input instead of asking here. And in cases where what
> they've read between the lines does not correspond to what GDB developers means,
> the result is a buggy frontend :-)
>
> Given that MI, presently, is still not adequate for such basic tasks as 
> listing local variables in a  function, it will change, and it might break 
> things, and frontend developers should provide the input to avoid surprises.
> You and Marc represent Eclipse here, and Nick represent Emacs, and 
> I represent KDevelop, so those three are fine, but other frontend developers
> should be more active here.
>
> Probably, I should add big warning to MI manual, saying that everything that is not
> 100% clear must be asked on the list.
>
> - Volodya
>   

Given how long (and for how many versions) GDB/MI has been around and 
how long it's been used by clients, you cannot simply make a disclaimer 
and change it at will without negative consequences to clients and 
indirectly to GDB.  It's kind of like common law marriage.  Common law 
marriage is a law in most states in the U.S. where if you live as a 
couple in the same house for so many years, you become legally married 
even if you never said the vows.  :-)

Cheers,
Pawel

Evolution of GDB/MI [was Re: MI non-stop interface details]

[Nick Roberts]

 > >                                                      Through its many 
 > > versions GDB has freely changed (or "cleaned up") the MI protocol in 
 > > subtle ways without warning (e.g. adding quotes around the condition 
 > > parameter in -break-condition).  This creates headaches for clients, and  
 > > can ultimately make the client code difficult to maintain. A perfect 
 > > example of this is the CDI-GDB Eclipse integration.  While it has other 
 > > architectural issues, the myriad of workarounds for various GDB versions 
 > > in it makes it difficult to know whether a change for latest GDB version 
 > > won't break support for old GDB versions.  What I don't think GDB 
 > > maintainers realize is that ultimately this policy does a lot of harm to 
 > > GDB adoption and GDB's reputation in the larger community.

I don't think it's a question of awareness.  Maintaining backward compatibility
is extra work for GDB developers while finding workarounds for different
versions is extra work for frontend developers.  While the former group tries
to consider the latter (united we stand, divided we fall) I think frontend
developers really need to take an active part in Gdb development if they expect
any kind of smooth ride.  Up till now, that has not really been the case for
Eclipse, although recently it does appear to be changing.

 > >                                                             I would 
 > > guess that most users of GDB have some kind of graphical interface and 
 > > their quality is linked to perception of quality of GDB.   GDB/MI is a 
 > > published protocol with many users, and I wish that this fact had more 
 > > significance to its maintainers.


 > GDB/MI is actually not a finished published protocol -- it's work in
 > progress.  Unfortunately, frontend maintainers tended to read between the
 > lines, and guess the behaviour and accepted input instead of asking
 > here. And in cases where what they've read between the lines does not
 > correspond to what GDB developers means, the result is a buggy frontend :-)

Well, it's described in the manual, so I guess it is published in that sense.
We have attempted to describe how GDB/MI might reasonably change in the future.
Perhaps now is the time to expand on that part of the documentation.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: MI non-stop interface details

[Marc Khouzam]

> > > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > > making the case of not passing a --thread parameter semantics
> > > match?  Given the same arguments, if one resumes just one thread,
> > > the others should too, IMHO.
> >
> > Too late. -exec-continue resumes everything. -exec-step, from user
> > standpoint, resumes one -- most users don't even know that step
> > can resume all threads.
> >
> 
> Oh, I'm talking non-stop mode.  It's not too late for that.
> 
> I played a bit with eclipse/java debugging (which implements non-stop),
> and noticed it only resumes one thread when one clicks the
> equivalent of "continue".  I have used eclipse/java heavilly in the
> past, and I never found that unintuitive.  I remember
> looking for a "continue all" button and not finding one, but normally
> I didn't even thing about it.  Resuming one thread was just fine.
> 
> (I keep thinking that in non-stop mode, the exec commands without
> --thread are equivalent to the CLI commands in non-stop mode.
> 
> I keep forgetting to pass --thread to continue& and end up
> resuming more than I wanted.)

I'm also leaning towards this: -exec-continue only continuing
the current thread, a la java.
Although, also having a 'continue all' may prove useful.

For curiosity, what will happen to GDB's 'current thread' if that
thread is continued, i.e., what if we have -exec-continue on a single
thread as suggested above, and we issue two -exec-continue in a row?

Thanks

Marc

Re: MI non-stop interface details

[Pedro Alves]

A Tuesday 29 April 2008 19:56:15, Marc Khouzam wrote:

> For curiosity, what will happen to GDB's 'current thread' if that
> thread is continued, i.e., what if we have -exec-continue on a single
> thread as suggested above, and we issue two -exec-continue in a row?
>

This isn't stricly related to the current thread.  What happens
if the frontend emits two '-exec-continue --thread="1"' ?
GDB will currently error out if a command tries to resume a
running thread. 

Currently:
 error ("Thread is already running");

Ignoring would also be a valid behaviour, I guess, although
an error condition is easier to define.

-- 
Pedro Alves

Re: MI non-stop interface details

[Vladimir Prus]

On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:
> Vladimir Prus wrote:
> > Again -- exec-continue resuming just one thread will be a change in behaviour.
> > We can take two approaches:
> >
> > 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
> > be used both in all-stop and non-stop mode). We're in position to change anything
> > we like, and are not bound by backward compatibility, or anything.
> >
> > 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
> > Pawel's opposition to the --thread idea indicates that he prefers this approach.
> > Then, we rather not change the behaviour of existing commands.
> >
> > There are not many high-level warts in MI2/non-stop/async, so I'm willing
> > to go with (2).
> >
> > - Volodya
> >   
> 
> First of all I really appreciate your effort to maintain backward 
> compatibility.  I know that it can seriously complicate the effort to 
> add new features but I believe this effort pays off in quicker and more 
> reliable adoption by the users (IDEs).  However, there are two kinds of 
> backward compatibility goals to consider:
> 1) Allowing old GDB clients to use the new, extended protocol.
> 2) Allow clients that use the extended protocol to easily work with old 
> protocol versions.  And by "easily", I mean that the client should be 
> able to not have "if(non-stop) { use command a } else { use command b}" 
> kind of logic scattered throughout its implementation.

Why do you have such a goal? 

> 
> Goal 1) is a little more obvious and it is being satisfied by having an 
> explicit all-stop/non-stop switch which has to be set in order to enable 
> the new protocol extensions. Goal 2) is somewhat more complicated and 
> difficult to achieve but I think it is possible with a few adjustments 
> to the current proposal.  (Note that the second goal is actually not 
> just about compatibility with older versions, it also has to do with 
> using the latest version of GDB with targets that don't support.) 
> non-stop mode.
> 
> As far as the protocol is concerned, I think the best way to think about 
> the difference between non-stop and all-stop is that all-stop is a 
> degenerate mode of non-stop where the all-stop mode has the limitation 
> that resuming a single thread always has the side effect of resuming the 
> entire process.  The first step in allowing the client to deal with this 
> difference is to add a field to the state change events which indicate 
> what context has actually changed state.  For this purpose I previously 
> suggested adding a "container-ids" parameter to the *resumed and 
> *stopped events.  In the extended protocol, this parameter would tell 
> the client whether the whole process was resumed or just a single 
> thread, and it should be present in either non-stop or all-stop mode.  

Currently, both *running and *stopped have "thread-id" field. 

> When working with older versions of GDB, this parameter would be absent, 
> which would allow the client to deduce that the whole process was resumed.

 
> The next problem to solve is the fact that non-stop needs an additional 
> feature: explicitly resuming/stopping/stepping the entire process.  
> That's right, if you think of all-stop as a degenerate mode, it's not 
> controlling the individual threads that is new, but it is controlling of 
> the entire process that needs to be added.  One way to add this feature 
> is to extend the run control commands to take a special parameter, i.e. 
> -all/--thread-id="all", etc.  The draw-back to this approach is that it 
> would still require the client to have the "if (non-stop)..." kind of 
> logic in its processing, because old versions of GDB would return an 
> error if they saw this option.  

And why is such conditional logic bad? I understand that adding 200 "if"
to codebase is both tedious and indicates a high risk of missing 10 more
places. I don't think that doing conditional behaviour if a few places
is bad.

> But there is a way around this (which I  
> proposed before but which I didn't receive any response about):  
> Designate thread "1" as the default container thread.  I.e. sending 
> "-exec-continue --thread-id="1"" would resume the entire process 
> ("-thread-select 1" followed by "-exec-continue") would do the same.  
> All other logic dealing with threads, -thread-list-ids, -thread-info, 
> etc could still work as it does today, it would just return threads 
> starting with id of "2".  When working with old versions of GDB, thread 
> 1 is always present, and since old versions of GDB implement all-stop 
> mode only, the resume-all button in the IDE would still work as expected.

In order versions of GDB, thread 1 is not always present. In particular,
on Linux x86, single-threaded applications are reported as having no thread.
Even if that were not true, I'm reluctant to add magic numbers of the
namespace of thread ids. 

> I assume there must be implementation complications to this propsal, but 
> as I've mentioned before, but I think it's worth considering as it would 
> also allow GDB to easily extend the MI protocol to support multi-process 
> debugging, where a new command:
> "-list-container-ids" would return the thread-ids of processes, and 
> "-list-thread-ids --thread-id="1"" would return threads within the given 
> container.

I'll probably start designing multi-process extensions for MI this week,
and will look into these suggestions. Why are you trying to use same
namespace for process ids and thread ids? 

- Volodya

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:
>   
>> Vladimir Prus wrote:
>>     
>>> Again -- exec-continue resuming just one thread will be a change in behaviour.
>>> We can take two approaches:
>>>
>>> 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
>>> be used both in all-stop and non-stop mode). We're in position to change anything
>>> we like, and are not bound by backward compatibility, or anything.
>>>
>>> 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
>>> Pawel's opposition to the --thread idea indicates that he prefers this approach.
>>> Then, we rather not change the behaviour of existing commands.
>>>
>>> There are not many high-level warts in MI2/non-stop/async, so I'm willing
>>> to go with (2).
>>>
>>> - Volodya
>>>   
>>>       
>> First of all I really appreciate your effort to maintain backward 
>> compatibility.  I know that it can seriously complicate the effort to 
>> add new features but I believe this effort pays off in quicker and more 
>> reliable adoption by the users (IDEs).  However, there are two kinds of 
>> backward compatibility goals to consider:
>> 1) Allowing old GDB clients to use the new, extended protocol.
>> 2) Allow clients that use the extended protocol to easily work with old 
>> protocol versions.  And by "easily", I mean that the client should be 
>> able to not have "if(non-stop) { use command a } else { use command b}" 
>> kind of logic scattered throughout its implementation.
>>     
>
> Why do you have such a goal? 
>   
Adoption of new versions of GDB is gradual, so for clients support for 
old versions of GDB is very important.
>> Goal 1) is a little more obvious and it is being satisfied by having an 
>> explicit all-stop/non-stop switch which has to be set in order to enable 
>> the new protocol extensions. Goal 2) is somewhat more complicated and 
>> difficult to achieve but I think it is possible with a few adjustments 
>> to the current proposal.  (Note that the second goal is actually not 
>> just about compatibility with older versions, it also has to do with 
>> using the latest version of GDB with targets that don't support.) 
>> non-stop mode.
>>
>> As far as the protocol is concerned, I think the best way to think about 
>> the difference between non-stop and all-stop is that all-stop is a 
>> degenerate mode of non-stop where the all-stop mode has the limitation 
>> that resuming a single thread always has the side effect of resuming the 
>> entire process.  The first step in allowing the client to deal with this 
>> difference is to add a field to the state change events which indicate 
>> what context has actually changed state.  For this purpose I previously 
>> suggested adding a "container-ids" parameter to the *resumed and 
>> *stopped events.  In the extended protocol, this parameter would tell 
>> the client whether the whole process was resumed or just a single 
>> thread, and it should be present in either non-stop or all-stop mode.  
>>     
>
> Currently, both *running and *stopped have "thread-id" field. 
>   
But your proposal doesn't add any fields to the events indicating 
whether the stopped event stops a single thread or the whole process.  
Even in non-stop mode alone this is important since commands can be 
issued to do both.
>   
>> When working with older versions of GDB, this parameter would be absent, 
>> which would allow the client to deduce that the whole process was resumed.
>>     
>
>  
>   
>> The next problem to solve is the fact that non-stop needs an additional 
>> feature: explicitly resuming/stopping/stepping the entire process.  
>> That's right, if you think of all-stop as a degenerate mode, it's not 
>> controlling the individual threads that is new, but it is controlling of 
>> the entire process that needs to be added.  One way to add this feature 
>> is to extend the run control commands to take a special parameter, i.e. 
>> -all/--thread-id="all", etc.  The draw-back to this approach is that it 
>> would still require the client to have the "if (non-stop)..." kind of 
>> logic in its processing, because old versions of GDB would return an 
>> error if they saw this option.  
>>     
>
> And why is such conditional logic bad? I understand that adding 200 "if"
> to codebase is both tedious and indicates a high risk of missing 10 more
> places. I don't think that doing conditional behaviour if a few places
> is bad.
>
>   
I think you answered your own question.  Even a few conditional changes 
in every release add up quickly.
>> But there is a way around this (which I  
>> proposed before but which I didn't receive any response about):  
>> Designate thread "1" as the default container thread.  I.e. sending 
>> "-exec-continue --thread-id="1"" would resume the entire process 
>> ("-thread-select 1" followed by "-exec-continue") would do the same.  
>> All other logic dealing with threads, -thread-list-ids, -thread-info, 
>> etc could still work as it does today, it would just return threads 
>> starting with id of "2".  When working with old versions of GDB, thread 
>> 1 is always present, and since old versions of GDB implement all-stop 
>> mode only, the resume-all button in the IDE would still work as expected.
>>     
>
> In order versions of GDB, thread 1 is not always present. In particular,
> on Linux x86, single-threaded applications are reported as having no thread.
> Even if that were not true, I'm reluctant to add magic numbers of the
> namespace of thread ids. 
>
>   
>> I assume there must be implementation complications to this propsal, but 
>> as I've mentioned before, but I think it's worth considering as it would 
>> also allow GDB to easily extend the MI protocol to support multi-process 
>> debugging, where a new command:
>> "-list-container-ids" would return the thread-ids of processes, and 
>> "-list-thread-ids --thread-id="1"" would return threads within the given 
>> container.
>>     
>
> I'll probably start designing multi-process extensions for MI this week,
> and will look into these suggestions. Why are you trying to use same
> namespace for process ids and thread ids? 
>
> - Volodya
>   
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.

Cheers,
Pawel

Re: MI non-stop interface details

[Vladimir Prus]

On Thursday 01 May 2008 22:06:03 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:
> >   
> >> Vladimir Prus wrote:
> >>     
> >>> Again -- exec-continue resuming just one thread will be a change in behaviour.
> >>> We can take two approaches:
> >>>
> >>> 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
> >>> be used both in all-stop and non-stop mode). We're in position to change anything
> >>> we like, and are not bound by backward compatibility, or anything.
> >>>
> >>> 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
> >>> Pawel's opposition to the --thread idea indicates that he prefers this approach.
> >>> Then, we rather not change the behaviour of existing commands.
> >>>
> >>> There are not many high-level warts in MI2/non-stop/async, so I'm willing
> >>> to go with (2).
> >>>
> >>> - Volodya
> >>>   
> >>>       
> >> First of all I really appreciate your effort to maintain backward 
> >> compatibility.  I know that it can seriously complicate the effort to 
> >> add new features but I believe this effort pays off in quicker and more 
> >> reliable adoption by the users (IDEs).  However, there are two kinds of 
> >> backward compatibility goals to consider:
> >> 1) Allowing old GDB clients to use the new, extended protocol.
> >> 2) Allow clients that use the extended protocol to easily work with old 
> >> protocol versions.  And by "easily", I mean that the client should be 
> >> able to not have "if(non-stop) { use command a } else { use command b}" 
> >> kind of logic scattered throughout its implementation.
> >>     
> >
> > Why do you have such a goal? 
> >   
> Adoption of new versions of GDB is gradual, so for clients support for 
> old versions of GDB is very important.

The "else" branch of your conditional handles old version of GDB, no?

> > Currently, both *running and *stopped have "thread-id" field. 
> >   
> But your proposal doesn't add any fields to the events indicating 
> whether the stopped event stops a single thread or the whole process.  

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.

> > I'll probably start designing multi-process extensions for MI this week,
> > and will look into these suggestions. Why are you trying to use same
> > namespace for process ids and thread ids? 
> >
> > - Volodya
> >   
> 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

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> On Thursday 01 May 2008 22:06:03 Pawel Piech wrote:
>   
>> Vladimir Prus wrote:
>>     
>>> On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:
>>>   
>>>       
>>>> Vladimir Prus wrote:
>>>>     
>>>>         
>>>>> Again -- exec-continue resuming just one thread will be a change in behaviour.
>>>>> We can take two approaches:
>>>>>
>>>>> 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
>>>>> be used both in all-stop and non-stop mode). We're in position to change anything
>>>>> we like, and are not bound by backward compatibility, or anything.
>>>>>
>>>>> 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
>>>>> Pawel's opposition to the --thread idea indicates that he prefers this approach.
>>>>> Then, we rather not change the behaviour of existing commands.
>>>>>
>>>>> There are not many high-level warts in MI2/non-stop/async, so I'm willing
>>>>> to go with (2).
>>>>>
>>>>> - Volodya
>>>>>   
>>>>>       
>>>>>           
>>>> First of all I really appreciate your effort to maintain backward 
>>>> compatibility.  I know that it can seriously complicate the effort to 
>>>> add new features but I believe this effort pays off in quicker and more 
>>>> reliable adoption by the users (IDEs).  However, there are two kinds of 
>>>> backward compatibility goals to consider:
>>>> 1) Allowing old GDB clients to use the new, extended protocol.
>>>> 2) Allow clients that use the extended protocol to easily work with old 
>>>> protocol versions.  And by "easily", I mean that the client should be 
>>>> able to not have "if(non-stop) { use command a } else { use command b}" 
>>>> kind of logic scattered throughout its implementation.
>>>>     
>>>>         
>>> Why do you have such a goal? 
>>>   
>>>       
>> Adoption of new versions of GDB is gradual, so for clients support for 
>> old versions of GDB is very important.
>>     
>
> The "else" branch of your conditional handles old version of GDB, no?
>   
As I mentioned before, having lots of "if (new)... else (old)..." makes 
the code hard to maintain after a while.  I think Nick got it right, 
maintaining backward compatibility is more work for the server, dealing 
with incompatibilities is more work for the client.  Right now what 
you're saying is: "what's the big deal, just do a little more work".  
Keep in mind though, there is one server, and many clients.
>   
>>> Currently, both *running and *stopped have "thread-id" field. 
>>>   
>>>       
>> But your proposal doesn't add any fields to the events indicating 
>> whether the stopped event stops a single thread or the whole process.  
>>     
>
> 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, 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.

Also this behavior is incompatible with the all-stop mode (in new or old 
GDB versions).  I.e. is the all-stop mode always going to report 
thread-id="all" for every stopped and running event?  I suppose you'll 
say to just add another if-else statement...
>>> I'll probably start designing multi-process extensions for MI this week,
>>> and will look into these suggestions. Why are you trying to use same
>>> namespace for process ids and thread ids? 
>>>
>>> - Volodya
>>>   
>>>       
>> 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?  Maybe implementers of other client can speak up on this. 

-Pawel

P.S. I really appreciate your effort and attention to resolve these issues.

Re: MI non-stop interface details

[Vladimir Prus]

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

Re: MI non-stop interface details

[Vladimir Prus]

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

Re: MI non-stop interface details

[Pawel Piech]

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.

-Pawel

Re: MI non-stop interface details

[Vladimir Prus]

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

Re: MI non-stop interface details

[Pawel Piech]

Vladimir Prus wrote:
> 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? 
Right.
> Frontend knows it already, no?
>
> - Volodya
>   
Right, it typically does... unless the command was issued through the 
CLI console, in which case the UI has to do some work to get it.  But as 
long as GDB has the information, it's simpler and more reliable to get 
it from the event.

-Pawel

Re: MI non-stop interface details

[Pawel Piech]

Vladimir,
Thank you for the update and thank you for incorporating our feedback in 
your proposal.  Having continued support for thread-select will make for 
a much smoother transition to this version of protocol.  I only have a 
couple of comments below:

Vladimir Prus wrote:
> There are a couple of open questions.
>
> 1. Presently, -exec-continue resumes all threads, and the current thread
> has no effect. I think it's desirable to be able to resume a single thread,
> and for that, we actually need the --thread option for -exec-continue, to
> mean that a single thread must be resumed.
> 2. Presently, -exec-step also resumes all threads. There's an option,
> "scheduler-locking" that can be used for cause -exec-step to resume only
> the current thread. It seems to be, that for non-stop mode, resuming all
> threads is a wrong thing to do, therefore -exec-step, when in non-stop
> mode, will resume only the thread been stepped. This will be the same
> no matter if the thread is specified implicitly or explicitly.
>   
I agree with Pedro Alves that having the behavior for -exec-* be 
consistent would be very helpful.  I would also suggest '-exec-continue 
--thread="all" '.  Now if we'd be able use '-thread-select all', that 
would be even better... though I suspect you'll see lots of 
implementation issues with that.

In either non-stop or all-stop mode, I expected to see extensions to the 
*stopped and *running events, which would indicate to the client whether 
one or all threads were resumed.  If you want to be very forward looking 
you could use:
*stopped,thread-id="2",thread-ids=[2, 3, 5],container-ids="[all]"...
where :
thread-id - Indicates the the thread that triggered the event, which is 
usually the thread that should receive the focus in the UI.
thread-ids - List of all threads that were suspended, threads that are 
part of the container that stopped would be omitted.
container-ids - list of containers (cores/processes/etc) that 
suspended.  Until multi-process support is implemented, "all" would be 
the only possible value.  Empty if only the thread suspended.


> Inferior function calls
> -----------------------
>
> We already have the *stopped async event, and I have a patch to introduce the
> *running async event. Those are not emitted when doing inferiour function calls,
> since doing so may cause a frontend to infinitely refresh its state. I propose
> the following mechanism to enable those notifications for frontends that
> are sufficiently robust:
>
> 1. Declare that MI might have some features that are not enabled by default.
> 2. Introduce new command -enable-feature, which takes a name of feature and enables
> it. 
> 3. Make up a name of a feature, say inferior_call_notifications, and add that
> feature to the output of -list-features.
> 4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
> for inferiour function calls.
>
> Any comments?
>   
This is a good compromise, would there be a special "reason" value, such 
as "evaluate"?

Thanks,
Pawel

Re: MI non-stop interface details

[Vladimir Prus]

On Wednesday 30 April 2008 18:34:48 Pedro Alves wrote:
> A Wednesday 30 April 2008 07:59:43, Vladimir Prus wrote:
> > On Tuesday 29 April 2008 21:48:51 Pedro Alves wrote:
> > > A Tuesday 29 April 2008 18:04:57, Vladimir Prus wrote:
> > > > > Pedro Alves wrote:
> > > > > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > > > > making the case of not passing a --thread parameter semantics
> > > > > match?  Given the same arguments, if one resumes just one thread,
> > > > > the others should too, IMHO.
> > > >
> > > > Too late. -exec-continue resumes everything. -exec-step, from user
> > > > standpoint, resumes one -- most users don't even know that step
> > > > can resume all threads.
> > >
> > > Oh, I'm talking non-stop mode.  It's not too late for that.
> > >
> > > I played a bit with eclipse/java debugging (which implements non-stop),
> > > and noticed it only resumes one thread when one clicks the
> > > equivalent of "continue".  I have used eclipse/java heavilly in the
> > > past, and I never found that unintuitive.  I remember
> > > looking for a "continue all" button and not finding one, but normally
> > > I didn't even thing about it.  Resuming one thread was just fine.
> >
> > Opinions differ. I think Eclipse behaviour optimized for non-common
> > cases. Maybe this non-stop behaviour is good for that J2EE kind of thing,
> > with zillion of threads, but it's not a good default behaviour for
> > debugging ordinary applications.
> >
> 
> Eh, indeed my experience is mostly with debugging live J2EE systems.
> It's also a bless to be able to hot-replace code while debugging, but
> well, java makes it easier to implement. :-)   I won't claim what
> is common or non-common without data.  Clearly, add a "resume all"
> button/shorcut and you get your "common" behaviour implemented.

I think it's the other way around -- add your "resume this thread" button,
and you get your custom behaviour :-)

> > > (I keep thinking that in non-stop mode, the exec commands without
> > > --thread are equivalent to the CLI commands in non-stop mode.
> > >
> > > I keep forgetting to pass --thread to continue& and end up
> > > resuming more than I wanted.)
> > >
> > > > > If we choose to always ignore the scheduler-locking setting
> > > > > in non-stop mode, by making them operate on the current thread
> > > > > only, we can still honour '-exec-continue --thread="all"',
> > > > > or '-exec-step --all'.  If people find it desirable, we can
> > > > > make "scheduler-locking off" with no --thread specified mean resume
> > > > > all threads.  That I tend to agree is wrong in non-stop mode.  I'd
> > > > > rather have two buttons on the IDE -- "resume" and "resume all",
> > > > > (or two keyboard shortcuts, etc.) then to export the sheduler-locking
> > > > > modes to the user interface.
> > > >
> > > > I guess we can redefine the behaviour of -exec-continue in non-stop, or
> > > > in MI3, but I worry that two different behaviours will make life too
> > > > hard for frontends (and for us)
> > >
> > > Oh, I was talking non-stop.
> >
> > I don't think that adding a bunch of "if (non_stop)" is gonna be a good
> > solution.
> 
> Oh well, on the GDB side, there's no way around it.  Inferior control
> in non-stop is different.  In non-stop, we have to resume every
> thread individually in common code, and while doing it, we have to
> make sure every thread is resumed with its context set.
> While in all-stop, there's always only one thread with an event to
> attend, and all other threads have been freezed by the debugger.  When
> we resume, in all-stop it's the target's responsibility to resume the
> frozen threads.
> A resume all in non-stop has also to take care of not resuming already
> running threads -- more accuratelly it's "resume-all-stopped".  This
> worry doesn't exist in all-stop.
> 
> Unless you were talking about that check in the frontend side.  Have
> no idea what would change, but I'd expect at least a bit of work to
> enable non-stop, just not a rewrite.
> 
> If we don't make "-exec-continue" resume only the selected thread, then
> a frontend not using "--thread" should set "set scheduler-locking on"
> to have a way of resuming just one thread, and GDB should
> honour scheduler-locking modes in non-stop mode.  This is the part
> I want to have settled, as I get to tweak to code :-)

Why a frontend would not use --thread for this specific command?

> 
> Does this mean "-exec-step" with no "--thread"
> and "scheduler-locking off" should step every stopped thread?  I assume
> not, it's not intuitive, but it's not really the same as in all-stop,
> where we step one thread and resume all others, which is a
> behaviour change too.

I don't believe making -exec-step step just current thread will be perceived
by users as a behaviour change. I bet most users don't know, and don't expect,
the -exec-step command to run random other threads, hit breakpoints in those
threads, etc.

> (Well, we could do non-stop do that too --step current, and
> resume others, meaning that non-stop with scheduler-locking off
> would be similar to all-stop, *except* we don't stop all threads
> when the step finishes...  If we do that in common code, then,
> it starts looking like we could turn "non-stop on" always, and
> implement all-stop on top of it -- not really sure if that should
> be a goal, or is it is possible at all, and I was going to defer
> thinking about it until later on, otherwise we'll never get this done.)

[Pedro and I discussed this a bit on IRC, and...]

On IRC, you said:

   [20:40] <pedro> in CLI it's lame to have to know the thread id, and to have to pass it to "continue".
   [20:43] <pedro> break 20; <hit breakpoint>; next; next; <hits other bkreapoint in another thread>; 
   another next; one step; continue; uuups, other thread resumed too...

I think this is valid point -- if user, in CLI, enables non-stop, then having "continue" just work,
resuming one thread, seems right. Are you going to add "--all" to "continue"? Going back to
-exec-continue, it's probably best to make it behave the same way as "continue", in non-stop mode.
This means that a frontend will have to conditionally pass "--all" to -exec-continue, but in
any way, if a frontend enables non-stop mode, is surely has to adjust some of the logic, and changing
-exec-continue logic does not seem too hard.

Thanks,
Volodya


 

Re: MI non-stop interface details

[Pedro Alves]

Vladimir,

A Thursday 01 May 2008 18:21:51, Vladimir Prus wrote:

> [Pedro and I discussed this a bit on IRC, and...]
>
> On IRC, you said:
>
>    [20:40] <pedro> in CLI it's lame to have to know the thread id, and to
> have to pass it to "continue". [20:43] <pedro> break 20; <hit breakpoint>;
> next; next; <hits other bkreapoint in another thread>; another next; one
> step; continue; uuups, other thread resumed too...
>
> I think this is valid point -- if user, in CLI, enables non-stop, then
> having "continue" just work, resuming one thread, seems right. Are you
> going to add "--all" to "continue"?

Sure!  I hereby volunteer to do that.  :-)

> Going back to -exec-continue, it's 
> probably best to make it behave the same way as "continue", in non-stop
> mode. This means that a frontend will have to conditionally pass "--all" to
> -exec-continue, but in any way, if a frontend enables non-stop mode, is
> surely has to adjust some of the logic, and changing -exec-continue logic
> does not seem too hard.
>

Exactly.  It's the same amount of work for a frontend writer either way.

If "-exec-continue" (without parameters) resumes all:

The frontend has to add new "resume one thread only button", which 
calls "-exec-continue --thread=x".  The current "resume" button,
already calling "-exec-continue", would resume all threads.

If "-exec-continue" (without parameters) resumes only current thread:

The frontend has to add new "resume all threads" button which 
calls "-exec-continue --thread=all".  The current "resume" button,
already calling "-exec-continue", would resume only the current
thread.

It's the same amount of work for a frontend writer, because
he'd have to write support for one of the new buttons.  In
an hypothetical world, where one could only have access to one
of these buttons, the most useful and general would be the
"resume (current thread)" one.  This means, that if the
frontend writer is lazy, it's better this way :-)

In my simplistic view of the frontend's world, I'd imagine that since
there's a *running notification telling the frontend which threads
resumed, the button actions doesn't have to care much which of the
behaviours (one thread or all-threads) it is triggering.  It's
the notification callback that has to care.

Thanks,
-- 
Pedro Alves