RE: MI non-stop interface details

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

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

On Tuesday 29 April 2008 22:56:15 Marc Khouzam 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.
> > 
> > (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.

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

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.

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

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.

-Pawel

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

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

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

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.

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

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