MI non-stop interface details

[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

On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
<vladimircodesourcery.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]

On Saturday 26 April 2008 20:21:38 Doug Evans wrote:
> On Sat, Apr 26, 2008 at 8:39 AM, Vladimir Prus
> <vladimircodesourcery.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

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

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

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

 

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

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

On Tuesday 29 April 2008 21:48:51 Pedro Alves wrote:
> 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.

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.

> (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.

- VOlodya


 

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 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 

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.

(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 Alves