MI non-stop mode spec

Making good used of GDB in async mode, and especially in
async non-stop
mode demands some changes in MI -- both general
clarifications, and actual
work to allow most MI commands while the target is running
and define
their behaviour.

I propose the changes as below. Please view this document as
spec
of how MI should ideally operate. In the cases where MI
currently
operates differently, there may be various transition plans,
including
deciding that current frontends won't be affected by change
anyway,
allowing earlier behaviour with a big warning in MI docs, or
bumping
MI version and implementing new behaviour only for MI3. This
spec does
not deal with such compatibility issues -- only with ideal
MI 
behaviour.

MI command details
==================

Legend:
(*) Changes from current MI behaviour.
(**) Changes from original non-stop mode proposal in
ht
tp://sourceware.org/ml/gdb/2007-11/msg00198.html
-> Todo items

General clarifications
----------------------

When operating in MI mode, gdb prints a prompt if and only
if it is ready to
immediately read and process the next command.  Of course, a
frontend can
send a command without waiting for the prompt, and it will
be eventually
processed.  However, if gdb has not printed a prompt after
the previous
command yet, it means that it might take a lot time until
the next command
will be executed.  The frontend may use the lack of prompt
to disable
some commands, or to show "waiting for previous command
to finish" 
indicator.

(*) Current MI syntax says that any result record must be
followed by a
prompt. For sync targets, this is wrong -- when gdb prints
^running
and resumes the target, it does not check for input, so
(gdb) is misleading.
When the target stops, the *stopped message, followed by the
prompt is
printed -- and it's at this point that gdb starts to accept
the input
again. So, I propose to remove the prompt right after
^running for the 
sync targets.
        
Each MI command results in either ^done, ^error, ^connected
or ^running
response. The ^connected response is basically identical to
^done, 
and the naming is different for historic reasons.  All of
those
except for ^running are immediately followed by prompt. The
^running
response means that the target has started running. Further
events
from the target will be reported using async notifications.

The async notifications are for various interesting events
that cannot
generally be reported as result of a command. For example, 
          
          =thread-created

is emitted whenever a new thread appears, and *stopped is
emitted whenever
target stops for any reason (generally, a stop in the target
is not
100% related to the execution command we were last doing,
for example
-exec-next can cause a breakpoint to be hit in unrelated
thread).

Because async notifications are not related to any given
command,
they don't, generally speaking, include the token of any
previous
MI command.

(*) Currently, the *stopped output does include the token
of
the last command.  However, it's implemented in limited way
--
if we allow any command except for -exec-interrupt in async
mode, the token printed for *stopped will be wrong. In
non-stop
mode, associating *stopped with a command is just
impossible.

Presently, MI spec says a command can output ^running just
once.
However, it the presense of breakpoint commands, it's quite
possible
that we resume one thread, hit a breakpoint, and breakpoint
commands
resume all threads, or some other thread.

To handle this case we need a new async output for this
case:

   *running,thread-id="xxx"

which is emitted whenever a previously stopped thread is
resumed.
In case all threads are resumed, "xxx" will be
"all".

Async/non-stop mode notes
-------------------------

The async mode basically means that gdb can process commands
even while
the target is running.  This mode is enabled whenever the
target is
async-capable.

In async mode, there are two further distinctions:
  - Should we allow an exec command while some other exec
command
  is already in progress?
  - Should we stop all threads whenever an event is detected
in one thread?

Those issues seem independent initially, so we might try to
allow
two -exec-next at one time, and then stop all threads when
any -exec-next
is finished.  However, that will require user to explicitly
resume the
-exec-next that is not yet finished, which does not seem
very helpful --
it's not much better than sending two -exec-next
sequentally.
Therefore, for now we shall have only two modes:

  - "all-stop", when all threads are stopped if
any thread stops,
  and when only one exec command is allowed to be active at
any given time,
  - "non-stop", where individual threads are
stopped, and several
  exec commands can be active.

Except for what is said above "all-stop" and
"non-stop" async modes are
identical. 

Generally, most MI commands are allowed while a target is
running, with the
following exceptions:

   - An execution command that logically applies to a single
thread 
   cannot be used if the thread is already running.  Global
-exec-continue is
   OK, and will resume all threads that are not presently
running. In all-stop
   mode an execution command cannot be started if any thread
is running.

   - Many commands in current MI operate on current thread. 
In non-stop
   mode, this creates a potential for race condition --
between the
   frontend sending a command to gdb and gdb reading that
command,
   gdb can detect a breakpoint and change the current
thread. Furthermore, in
   case when a frontend sends a series of commands and gdb
detects a thread
   stop in between, it's plain impossible to figure if the
second command
   should be executed in the originally current thread, or
in the thread
   were stop was detected. For that reason, in non-stop mode
all MI commands
   that require a thread will require the frontend to
specify the thread
   explicitly.  

          Note: stateless protocol will not only be more
robust in
          non-stop mode, but actually simplify frontends.
Say, in CDT
          there are several places were we switch a thread,
do some operation,
          and then switch back to the original thread. Say,

          Thread.getStackFrameCount or
Target.evaluateExpressionToString.
          
   - Some data access commands are also implicitly using a
specific thread --
   because they are using registers, or variables in
specific thread/frame,
   or because they have to call a function in the inferior.
Such data access
   commands are not allowed when the necessary thread is
running. Wholesale
   update operations like -var-update will plain ignore
variable objects
   that need now-running threads.

   - The commands that grab global state of the target are
allowed when 
   some threads are running.  It should be understood that
the result may
   be inaccurate -- in particular, the memory content can
change while
   we read it, and the list of threads might not be updated
until some
   event from the target arrives. In addition, some targets
might not   
   even allow reading memory while all threads are running
-- so memory
   access commands on such targets will require that at
least one thread
   is stopped.

To simplify things, if GDB is started in MI mode, no CLI
command is allowed
while the target is running, and -interpreter-exec is not
allowed either.

   Note: in cases when to implement a command, GDB requires
that at least
   one (or all) threads are stopped, and the command is
issued when this
   condition is not met, we have two choices -- issue an
error, or briefly
   stop the target, perform the operation, and resume.
Clearly, doing
   that in GDB (or even in the target) will be less
intrusive then doing
   that in frontend.  However, it might be still too
intrusive. For now,
   we'll just emit error, should a real need arise, we can
always implement
   automatic interruption of the target.   

MI commands changes
-------------------

    (**) There are two new options that a number of MI
commands may take:

          --thread <id>

    option specifies the id of the thread the command should
operate on.

           --global

    specifies that the command should operate on no thread,
but on 
    global data.  This option is necessary to distinguish
the case where
    the frontend has forgot to specify --thread, assuming
that the current
    thread will be used, from the case when frontend
explicitly wants
    to execute a command in global scope.  This clarify of
intention
    is particularly important when the "current
thread" is running.

    - Break commands. All breakpoints commands are allowed
at any time
    and the changes are applied to the program immediately.
    The output of -break-list and -break-info in general
should be considered
    invalid as soon as a stop in any thread is reported. The
break commands
    generally don't care about current thread and frame.
    If -break-insert command specifies only line number,
then it implicitly
    depends on the filename of the current thread/frame. In
non-stop mode,
    the frontend is required to specify thread and frame
explicitly.

    - Program context commands. Those are not allowed after
the program
    has started execution.

    - Thread commands. The -thread-info command should be
implemented (a
    patch is already posted).
    (**) The -thread-list-all-threads is not necessary with
the current
    behaviour of -thread-info.
    (**) The -thread-select command is only allowed on the
that that is
    currently stopped.  This command should not generally be
used in
    non-stop mode.
   
    - Program execution. The -exec-next, -exec-step,
-exec-finish, 
    -exec-until, -exec-return, -exec-step-instruction and 
    -exec-next-instruction command require --thread
parameter. Also,
    those commands resume strictly the thread that is being
stepped,
    equivalent to "scheduler-locking on". 
    The -exec-continue command with the --thread parameter
will resume
    just one thread, whereas -exec-continue without a
--thread parameter
    will resume all threads that are not presently running.

    - Stack commands. All are allowed. All require a thread
parameter in
    non-stop mode.

    - Variable objects. The -var-create command requires
either the
    --thread or --global option. If --thread is specified,
then the
    referred thread must be stopped. With --global, 
    varobj's expression is evaluated in the global scope.
    If a variable object makes use of any local variable,
the object 
    becomes bound to the
    thread where it was created.  An attempt to manipulate
an
    individual variable obect when the thread it is bound to
is not
    stopped results in an error. As a special exception,
-var-update will
    ignore any variable object whose bound thread is not
stopped.
    A variable object's expression might involve a function
call.  If a
    variable object is not bound to any thread, the function
call will be
    executed in any currently stopped thread.

        Note: this does allow creating a global varobj while
all threads
        are running.  If the target does not allow accessing
memory when
        all threads are running, such a varobj will only get
any value
        at a later time.

        -> Should  varobjs be bound to only thread, or to
nothing at all.
    
    - Data manipulation. All commands are supported, except
for
    data-list-changed-registers, which is presently
thread-unaware and seems
    inferior to using variable objects anyway. 
    The -data-evaluate-expression and
-data-list-register-values requires
    that either the --thread or the --global option be
provided.

    - Symbol query commands. All are supported.
    
    - File commands. The -file-exec-and-symbols and
-file-exec-file cannot
    be used when any thread is running.  The
-file-list-shared-libraries
    can be used while inferior is running, but the results
might be
    invalidated immediately. Same for
-file-list-symbol-files. Others
    can be used without limitations.

    On some targets it might not be possible to get the list
of shared 
    libraries from the target while it is running. In such
cases, GDB will
    report an error.

    - Target manipulation. The -target-disconnect can be
used while threads
    are running. Other (currently implemented) commands can
only
    be used before we have an executable.

    - File transfer. Can be always used.

    - Misc. Case-by-case, nothing interesting.

 > (*) Current MI syntax says that any result record must
be followed by a
 > prompt. For sync targets, this is wrong -- when gdb
prints ^running
 > and resumes the target, it does not check for input,
so (gdb) is misleading.
 > When the target stops, the *stopped message, followed
by the prompt is
 > printed -- and it's at this point that gdb starts to
accept the input
 > again. So, I propose to remove the prompt right after
^running for the 
 > sync targets.

It's not a prompt, just a delimiter.  For a start it has a
newline after it.
Furthermore if you change the prompt with "set
prompt", it doesn't change.

       
 > Each MI command results in either ^done, ^error,
^connected or ^running
 > response. The ^connected response is basically
identical to ^done, 
 > and the naming is different for historic reasons.  All
of those
 > except for ^running are immediately followed by
prompt. The ^running
 > response means that the target has started running.
Further events
 > from the target will be reported using async
notifications.
 > 
 > The async notifications are for various interesting
events that cannot
 > generally be reported as result of a command. For
example, 
 >           
 >           =thread-created

This notification doesn't appear to be in the manual.  Why
are there no
equivalent =thread-exited notifications?


 >...
 > Presently, MI spec says a command can output ^running
just once.
 > However, it the presense of breakpoint commands, it's
quite possible
 > that we resume one thread, hit a breakpoint, and
breakpoint commands
 > resume all threads, or some other thread.
 > 
 > To handle this case we need a new async output for
this case:
 > 
 >    *running,thread-id="xxx"

      ^running,thread-id="xxx" ? 
("running" isn't an out-of-bound record)


 > which is emitted whenever a previously stopped thread
is resumed.
 > In case all threads are resumed, "xxx" will
be "all".
 > To simplify things, if GDB is started in MI mode, no
CLI command is allowed
 > while the target is running, and -interpreter-exec is
not allowed either.

If you can make this work with MI commands, it should be
easy to add CLI
commands to do the same thing.  I will do this.


 >... 
 >     - Thread commands. The -thread-info command should
be implemented (a
 >     patch is already posted).

Notice that there is currently an inconsistency here:

  -exec-run
  ^running
  (gdb) 
 
*stopped,reason="breakpoint-hit",bkptno="1&qu
ot;,thread-id="0",...
                                              ^^^^^^^^^^^^
while

  (gdb) 
  -thread-info
  ^done,threads=[]
  (gdb) 
  -thread-info 0
  ^done,threads=[]
  (gdb) 
  b main thread 0 
  &"b main thread 0n"
  &"Unknown thread 0.n"
  ^error,msg="Unknown thread 0."
  (gdb) 

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

 > > It's not a prompt, just a delimiter.  For a start
it has a newline after
 > > it.  Furthermore if you change the prompt with
"set prompt", it doesn't
 > > change.
 > 
 > Let's call (gdb) a "MI prompt", then. Given
that each MI output is already
 > terminated with a newline, (gdb) is not necessary to
property parse MI
 > output. Then, the question is that does (gdb) mean?

Well I've not tried to parse the MI output on it's own, in
earnest, yet but if
it's a delimiter then means that the parser can find the end
of the output
record.

 >                                                     If
it does not mean 
 > anything, it should be, ideally, just removed. And if
it means anything,
 > then what? Current behaviour is not consistent, but
the code suggests
 > that it's meant to indicate when GDB is ready for a
new command. I think
 > such a behaviour will be useful for a frontend.

If it stays, the frontend can just use the rule that GDB is
ready for a new
command after "(gdb)n" unless it's preceded by
^running.

 > >  > Each MI command results in either ^done,
^error, ^connected or ^running
 > >  > response. The ^connected response is
basically identical to ^done,
 > >  > and the naming is different for historic
reasons.  All of those
 > >  > except for ^running are immediately
followed by prompt. The ^running
 > >  > response means that the target has started
running. Further events
 > >  > from the target will be reported using
async notifications.
 > >  > 
 > >  > The async notifications are for various
interesting events that cannot
 > >  > generally be reported as result of a
command. For example,
 > >  >           
 > >  >           =thread-created
 > > 
 > > This notification doesn't appear to be in the
manual.  
 > 
 > Because I'm still working for a doc patch for same.

According to the syntax, as above, this should be:

     =thread-created,id="3"
     (gdb)

 > > Why are there no 
 > > equivalent =thread-exited notifications?
 > 
 > Because it's not implemented. 

Does that mean that you think that =thread-created is more
useful?

 > Note that current thread.c implementation will only
declare a thread as done
 > when we do -thread-info (or anything else that calls
prune_threads, so the
 > value of =thread-exited will be limited, without some
associated work on
 > threads layer).

I'm not sure what you mean.  If I run Gdb normally with a
multi-threaded
application, I get:

[New Thread -1210639472 (LWP 7235)]

when a thread is created and:

[Thread -1210639472 (LWP 7235) exited]

when it is terminated.


 > >  > Presently, MI spec says a command can
output ^running just once.
 > >  > However, it the presense of breakpoint
commands, it's quite possible
 > >  > that we resume one thread, hit a
breakpoint, and breakpoint commands
 > >  > resume all threads, or some other thread.
 > >  > 
 > >  > To handle this case we need a new async
output for this case:
 > >  > 
 > >  >    *running,thread-id="xxx"
 > > 
 > >       ^running,thread-id="xxx" ? 
("running" isn't an out-of-bound record)
 > 
 > "*running" is the new async output proposed
by this spec (and async-output
 > is a kind of out-of-bound record). We cannot use
^running, because ^running
 > is emitted once for each command, and each command can
resume the target
 > several times, and possibly - different threads.

Breakpoint command lists don't currently work in MI, so your
scenario is a bit
hypothetical, but if they did then it's quite possible that
we hit a breakpoint
on one thread and breakpoint commands resume all threads
without async mode.

It probably doesn't matter that much if you use
"*running" or "^running" and
you can probably define asynchronous in different ways but I
think starting
execution and detecting stopped execution different in this
respect.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Wednesday 19 March 2008 12:14:19 Nick Roberts wrote:
>  > > It's not a prompt, just a delimiter.  For a
start it has a newline after
>  > > it.  Furthermore if you change the prompt
with "set prompt", it doesn't
>  > > change.
>  > 
>  > Let's call (gdb) a "MI prompt", then.
Given that each MI output is already
>  > terminated with a newline, (gdb) is not necessary
to property parse MI
>  > output. Then, the question is that does (gdb)
mean?
> 
> Well I've not tried to parse the MI output on it's own,
in earnest, yet but if
> it's a delimiter then means that the parser can find
the end of the output
> record.

And what's the practical value? Both KDevelop and CDT parse
MI output line-by-line,
and it appears to be just enough.

>  >                                                  
  If it does not mean 
>  > anything, it should be, ideally, just removed.
And if it means anything,
>  > then what? Current behaviour is not consistent,
but the code suggests
>  > that it's meant to indicate when GDB is ready for
a new command. I think
>  > such a behaviour will be useful for a frontend.
> 
> If it stays, the frontend can just use the rule that
GDB is ready for a new
> command after "(gdb)n" unless it's preceded
by ^running.

Which happens to be wrong. In async mode, gdb *may* be ready
for a new
command even if ^running is output. And whether it's ready
or not, generally
depends on the command

>  > >  > Each MI command results in either
^done, ^error, ^connected or ^running
>  > >  > response. The ^connected response is
basically identical to ^done,
>  > >  > and the naming is different for
historic reasons.  All of those
>  > >  > except for ^running are immediately
followed by prompt. The ^running
>  > >  > response means that the target has
started running. Further events
>  > >  > from the target will be reported using
async notifications.
>  > >  > 
>  > >  > The async notifications are for
various interesting events that cannot
>  > >  > generally be reported as result of a
command. For example,
>  > >  >           
>  > >  >           =thread-created
>  > > 
>  > > This notification doesn't appear to be in
the manual.  
>  > 
>  > Because I'm still working for a doc patch for
same.
> 
> According to the syntax, as above, this should be:
> 
>      =thread-created,id="3"
>      (gdb)

And what is the value of (gdb) here?
 
>  > > Why are there no 
>  > > equivalent =thread-exited notifications?
>  > 
>  > Because it's not implemented. 
> 
> Does that mean that you think that =thread-created is
more useful?

It's easy to implement.
 
>  > Note that current thread.c implementation will
only declare a thread as done
>  > when we do -thread-info (or anything else that
calls prune_threads, so the
>  > value of =thread-exited will be limited, without
some associated work on
>  > threads layer).
> 
> I'm not sure what you mean.  If I run Gdb normally with
a multi-threaded
> application, I get:
> 
> [New Thread -1210639472 (LWP 7235)]
> 
> when a thread is created and:
> 
> [Thread -1210639472 (LWP 7235) exited]
> 
> when it is terminated.

At which point, and where in code is that message printed?
It is
printed by linux-thread-db.c:detach_thread, so it's not good
for
generic code. And generic code will hold on to thread until

"info thread". It's not very good if you need to
issue "info thread"
to get notifications about exited thread.

So, thread.c and its interaction with linux-thread-db.c have
to
be fixed.

>  > >  > Presently, MI spec says a command can
output ^running just once.
>  > >  > However, it the presense of breakpoint
commands, it's quite possible
>  > >  > that we resume one thread, hit a
breakpoint, and breakpoint commands
>  > >  > resume all threads, or some other
thread.
>  > >  > 
>  > >  > To handle this case we need a new
async output for this case:
>  > >  > 
>  > >  >    *running,thread-id="xxx"
>  > > 
>  > >       ^running,thread-id="xxx" ? 
("running" isn't an out-of-bound record)
>  > 
>  > "*running" is the new async output
proposed by this spec (and async-output
>  > is a kind of out-of-bound record). We cannot use
^running, because ^running
>  > is emitted once for each command, and each
command can resume the target
>  > several times, and possibly - different threads.
> 
> Breakpoint command lists don't currently work in MI, 

Do you suggest they should never work? They probably don't
work because nobody
tried to make them -- we have a call to bpstat_do_actions in

mi_interpreter_exec_continuation so we try to do them only
for CLI commands,
and only in async mode.

> so your scenario is a bit 
> hypothetical, but if they did then it's quite possible
that we hit a breakpoint
> on one thread and breakpoint commands resume all
threads without async mode.

Yes, and what's wrong about that? We still need to
accurately report to
the frontend which threads are running, so that the frontend
does not
allow the user to mess with the currently running threads.

> It probably doesn't matter that much if you use
"*running" or "^running" and
> you can probably define asynchronous in different ways
but I think starting
> execution and detecting stopped execution different in
this respect.

I have a simple goal -- at any point, the frontend should
know exactly:

1. Which threads are there.
2. Which threads are running or not

The second requires that we always report when
currently-stopped thread
gets running, and this might require more than one
notification. Since ^running
is now specified as emitted once we have the following
choices:

1. Say that ^running can be emitted several time. But then,
why can't be allow
^done to be emitted many times? And if we do, the point of ^
responses disppear.
2. Say that ^running is bad design to begin with. Replace
^running with *running.
Declare that -exec commands result in ^done.
3. Leave ^running along. Add *running that naturally can be
printed several
times.

I personally prefer (2), but it's more drastic change for
frontends, so
I've suggested (3) for now.

- Volodya

On Wed, Mar 19, 2008 at 12:16:01AM +0300, Vladimir Prus
wrote:
> 
> Making good used of GDB in async mode, and especially
in async non-stop
> mode demands some changes in MI -- both general
clarifications, and actual
> work to allow most MI commands while the target is
running and define
> their behaviour.

Do you mind posting an updated grammar for the GDB/MI
changes that you
are making? or at least just a diff of it?

I currently maintain a gdb/mi bison parser that i have not
put into 
production use yet. However, the time for this is coming, I
will 
probably start working on this again after all of these
changes get 
through.

At one point, I would parse all of the output of gdb/mi that
came
from running 'make check' in the gdb.mi testsuite. If you
would like,
I could do that again after your patch, and let you know
where it
breaks.

Thanks,
Bob Rossi

On Wed, Mar 19, 2008 at 09:25:39AM +0300, Vladimir Prus
wrote:
> Nick Roberts wrote:
> 
> >  > (*) Current MI syntax says that any result
record must be followed by a
> >  > prompt. For sync targets, this is wrong --
when gdb prints ^running
> >  > and resumes the target, it does not check
for input, so (gdb) is misleading.
> >  > When the target stops, the *stopped message,
followed by the prompt is
> >  > printed -- and it's at this point that gdb
starts to accept the input
> >  > again. So, I propose to remove the prompt
right after ^running for the
> >  > sync targets.
> > 
> > It's not a prompt, just a delimiter.  For a start
it has a newline after it.
> > Furthermore if you change the prompt with
"set prompt", it doesn't change.
> 
> Let's call (gdb) a "MI prompt", then. Given
that each MI output is already
> terminated with a newline, (gdb) is not necessary to
property parse MI
> output. Then, the question is that does (gdb) mean? If
it does not mean 
> anything, it should be, ideally, just removed. And if
it means anything,
> then what? Current behaviour is not consistent, but the
code suggests
> that it's meant to indicate when GDB is ready for a new
command. I think
> such a behaviour will be useful for a frontend.

Exactly, "(gdb)" means nothing except, 
  output ==>
      ( out-of-band-record )* [ result-record ]
"(gdb)" nl
exactly that. It is the end of the output record. I can tell
you that my
parser can probably handle not having (gdb) in it, because
the "(gdb)"
isn't the end symbol, the newline is. In fact, look at my
grammar here,
  output: 
    opt_oob_record_list opt_result_record OPEN_PAREN
variable CLOSED_PAREN NEWLINE {

You can see that I could probably remove the 
  OPEN_PAREN variable CLOSED_PAREN
part, and simply look for the NEWLINE. In fact, if I remove
them, I do
not get an error from bison.

So, yes, it is there for absolutely no reason. However, if
you are using
a more adhoc parser than mine, I bet you might find that you
just do
need that "(gdb)" there!

Bob Rossi

On Wednesday 19 March 2008 14:09:38 Bob Rossi wrote:
> On Wed, Mar 19, 2008 at 12:16:01AM +0300, Vladimir Prus
wrote:
> > 
> > Making good used of GDB in async mode, and
especially in async non-stop
> > mode demands some changes in MI -- both general
clarifications, and actual
> > work to allow most MI commands while the target is
running and define
> > their behaviour.
> 
> Do you mind posting an updated grammar for the GDB/MI
changes that you
> are making? or at least just a diff of it?

The following changes will happen:

	output ==> 
	( out-of-band-record )* [ result-record ] "(gdb)"
nl

becomes:

	output ==>

		( out-of-band-record | result-record | "(gdb)" )
nl


then

	async-class ==> 
		"stopped" | others (where others will be added
depending on the needs--this is still in development).

becomes:

	async-class ==> 
	 "stopped" | "running" |
"thread-created" | others (where others will be
added depending on the needs--this is still in
development).


> I currently maintain a gdb/mi bison parser that i have
not put into 
> production use yet. However, the time for this is
coming, I will 
> probably start working on this again after all of these
changes get 
> through.

Except for the 'output' change -- which essentially codifies
that
MI output is a sequence of almost independent lines, I don't
think
there are further changes to the grammar planned except for
adding
new async-classes.
 
> At one point, I would parse all of the output of gdb/mi
that came
> from running 'make check' in the gdb.mi testsuite. If
you would like,
> I could do that again after your patch, and let you
know where it
> breaks.

That would be good, thanks.

- Volodya

 > > Well I've not tried to parse the MI output on
it's own, in earnest, yet
 > > but if it's a delimiter then means that the
parser can find the end of the
 > > output record.
 > 
 > And what's the practical value? Both KDevelop and CDT
parse MI output
 > line-by-line, and it appears to be just enough.

Maybe you're right but the "(gdb) n" doesn't seem
to cost much.

 > >  >                                            
        If it does not mean 
 > >  > anything, it should be, ideally, just
removed. And if it means anything,
 > >  > then what? Current behaviour is not
consistent, but the code suggests
 > >  > that it's meant to indicate when GDB is
ready for a new command. I think
 > >  > such a behaviour will be useful for a
frontend.
 > > 
 > > If it stays, the frontend can just use the rule
that GDB is ready for a new
 > > command after "(gdb)n" unless it's
preceded by ^running.
 > 
 > Which happens to be wrong. In async mode, gdb *may* be
ready for a new
 > command even if ^running is output. And whether it's
ready or not, generally
 > depends on the command

In async mode Gdb is pretty much always ready for a new
command isn't it?

 >  > >  >...
 > > Breakpoint command lists don't currently work in
MI, 
 > 
 > Do you suggest they should never work? 

No, but breaking my sentence here might make it appear that
I did.

 >                                         They probably
don't work because
 > nobody tried to make them -- we have a call to
bpstat_do_actions in
 > mi_interpreter_exec_continuation so we try to do them
only for CLI commands,
 > and only in async mode.

CLI commands like "commands" that query the user
don't fit well with MI.
Apple have created an MI command called -break-commands
which gets round
this problem for "commands".

 > > so your scenario is a bit hypothetical, but if
they did then it's quite
 > > possible that we hit a breakpoint on one thread
and breakpoint commands
 > > resume all threads without async mode.
 > 
 > Yes, and what's wrong about that? We still need to
accurately report to
 > the frontend which threads are running, so that the
frontend does not
 > allow the user to mess with the currently running
threads.

There's nothing "wrong" about that, just that
apart from adding the thread id,
I can't see much difference to the present case.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Wednesday 19 March 2008 15:00:29 Nick Roberts wrote:
>  > > Well I've not tried to parse the MI output
on it's own, in earnest, yet
>  > > but if it's a delimiter then means that the
parser can find the end of the
>  > > output record.
>  > 
>  > And what's the practical value? Both KDevelop and
CDT parse MI output
>  > line-by-line, and it appears to be just enough.
> 
> Maybe you're right but the "(gdb) n" doesn't
seem to cost much.

It make it impossible to know if gdb is ready for input.

>  > >  >                                       
             If it does not mean 
>  > >  > anything, it should be, ideally, just
removed. And if it means anything,
>  > >  > then what? Current behaviour is not
consistent, but the code suggests
>  > >  > that it's meant to indicate when GDB
is ready for a new command. I think
>  > >  > such a behaviour will be useful for a
frontend.
>  > > 
>  > > If it stays, the frontend can just use the
rule that GDB is ready for a new
>  > > command after "(gdb)n" unless
it's preceded by ^running.
>  > 
>  > Which happens to be wrong. In async mode, gdb
*may* be ready for a new
>  > command even if ^running is output. And whether
it's ready or not, generally
>  > depends on the command
> 
> In async mode Gdb is pretty much always ready for a new
command isn't it?

Not necessary. For example, presently calling of function in
inferior is
not async, and making it async is fairly complex.

>  >  > >  >...
>  > > Breakpoint command lists don't currently
work in MI, 
>  > 
>  > Do you suggest they should never work? 
> 
> No, but breaking my sentence here might make it appear
that I did.
> 
>  >                                         They
probably don't work because
>  > nobody tried to make them -- we have a call to
bpstat_do_actions in
>  > mi_interpreter_exec_continuation so we try to do
them only for CLI commands,
>  > and only in async mode.
> 
> CLI commands like "commands" that query the
user don't fit well with MI.

Well, I can set breakpoint commands in MI just fine, it's
just they
are not run.

> Apple have created an MI command called -break-commands
which gets round
> this problem for "commands".

Yes, it's not very hard to grab, in fact.
 
>  > > so your scenario is a bit hypothetical, but
if they did then it's quite
>  > > possible that we hit a breakpoint on one
thread and breakpoint commands
>  > > resume all threads without async mode.
>  > 
>  > Yes, and what's wrong about that? We still need
to accurately report to
>  > the frontend which threads are running, so that
the frontend does not
>  > allow the user to mess with the currently running
threads.
> 
> There's nothing "wrong" about that, just that
apart from adding the thread id,
> I can't see much difference to the present case.
 
Is it either:
1. You don't believe that a single command can result in
more than one resumption,
of different threads?
2. You think it's fine to emit ^running several times?

- Volodya

On Wed, Mar 19, 2008 at 02:19:39PM +0300, Vladimir Prus
wrote:
> On Wednesday 19 March 2008 14:09:38 Bob Rossi wrote:
> > On Wed, Mar 19, 2008 at 12:16:01AM +0300, Vladimir
Prus wrote:
> > > 
> > > Making good used of GDB in async mode, and
especially in async non-stop
> > > mode demands some changes in MI -- both
general clarifications, and actual
> > > work to allow most MI commands while the
target is running and define
> > > their behaviour.
> > 
> > Do you mind posting an updated grammar for the
GDB/MI changes that you
> > are making? or at least just a diff of it?
> 
> The following changes will happen:
> 	output ==> 
> 	( out-of-band-record )* [ result-record ]
"(gdb)" nl
> becomes:
> 	output ==>
> 		( out-of-band-record | result-record |
"(gdb)" ) nl

OK, something seems wrong here. 

Previously, you could have 0 or more out-of-band-records.
That could be
followed by a result-record, but didn't have to be, and then
the obvious
"(gdb)" nl.

Now you are saying you must have 1 out-of-band-record
followed by 1 result-record. 
Is this what you intended to say? I mean, currently, how
would that
support handling multiples lines of output from the inferior
on stdout?

> then
> 	async-class ==> 
> 		"stopped" | others (where others will be
added depending on the needs--this is still in
development).
> becomes:
> 	async-class ==> 
> 	 "stopped" | "running" |
"thread-created" | others (where others will be
added depending on the needs--this is still in
development).

OK, makes perfect sense.

> > I currently maintain a gdb/mi bison parser that i
have not put into 
> > production use yet. However, the time for this is
coming, I will 
> > probably start working on this again after all of
these changes get 
> > through.
> 
> Except for the 'output' change -- which essentially
codifies that
> MI output is a sequence of almost independent lines, I
don't think
> there are further changes to the grammar planned except
for adding
> new async-classes.

OK, that's great. Please think about the request I'm going
to make, I
think it's very important. I think the first thing gdb
should do is
output a single line (a header) that tells the version that
mi is going
to use during this communication, and the current versions
that the 
particular gdb supports.

The more we bump the MI revisions, the more it is going to
take time for
front ends to continually start gdb, probing for the best
version it 
supports.

I can submit a patch for this, if you don't feel like doing
it.

> > At one point, I would parse all of the output of
gdb/mi that came
> > from running 'make check' in the gdb.mi testsuite.
If you would like,
> > I could do that again after your patch, and let
you know where it
> > breaks.
> 
> That would be good, thanks.

Ok, I'll do that once we have resolved what you expect the
grammar to
be.

Bob Rossi

On Wednesday 19 March 2008 16:41:34 Bob Rossi wrote:
> On Wed, Mar 19, 2008 at 02:19:39PM +0300, Vladimir Prus
wrote:
> > On Wednesday 19 March 2008 14:09:38 Bob Rossi
wrote:
> > > On Wed, Mar 19, 2008 at 12:16:01AM +0300,
Vladimir Prus wrote:
> > > > 
> > > > Making good used of GDB in async mode,
and especially in async non-stop
> > > > mode demands some changes in MI -- both
general clarifications, and actual
> > > > work to allow most MI commands while the
target is running and define
> > > > their behaviour.
> > > 
> > > Do you mind posting an updated grammar for
the GDB/MI changes that you
> > > are making? or at least just a diff of it?
> > 
> > The following changes will happen:
> > 	output ==> 
> > 	( out-of-band-record )* [ result-record ]
"(gdb)" nl
> > becomes:
> > 	output ==>
> > 		( out-of-band-record | result-record |
"(gdb)" ) nl
> 
> OK, something seems wrong here. 
> 
> Previously, you could have 0 or more
out-of-band-records. That could be
> followed by a result-record, but didn't have to be, and
then the obvious
> "(gdb)" nl.
> 
> Now you are saying you must have 1 out-of-band-record
followed by 1 result-record. 
> Is this what you intended to say? I mean, currently,
how would that
> support handling multiples lines of output from the
inferior on stdout?

The above grammar say that gdb outputs either:

1. out-of-band record,
2. result record
3. prompt

and that any of those is followed by a newline. So, you can
have 100 out-of-band-records, followed by result record,
followed by
prompt, followed by some more out-of-band records.

The 'output' nonterminal does not describe all the output
that gdb might produce during entire run, it describes a
single line
that gdb might output.

> 
> > then
> > 	async-class ==> 
> > 		"stopped" | others (where others will
be added depending on the needs--this is still in
development).
> > becomes:
> > 	async-class ==> 
> > 	 "stopped" | "running" |
"thread-created" | others (where others will be
added depending on the needs--this is still in
development).
> 
> OK, makes perfect sense.
> 
> > > I currently maintain a gdb/mi bison parser
that i have not put into 
> > > production use yet. However, the time for
this is coming, I will 
> > > probably start working on this again after
all of these changes get 
> > > through.
> > 
> > Except for the 'output' change -- which
essentially codifies that
> > MI output is a sequence of almost independent
lines, I don't think
> > there are further changes to the grammar planned
except for adding
> > new async-classes.
> 
> OK, that's great. Please think about the request I'm
going to make, I
> think it's very important. I think the first thing gdb
should do is
> output a single line (a header) that tells the version
that mi is going
> to use during this communication, and the current
versions that the 
> particular gdb supports.
> 
> The more we bump the MI revisions, the more it is going
to take time for
> front ends to continually start gdb, probing for the
best version it 
> supports.
> 
> I can submit a patch for this, if you don't feel like
doing it.

We should see what the final changes will be. Probably, we
can announce
them using the existing -list-features command and then add
a mechanism
to enable new behaviour with a MI command.

Of course, if that proves unsufficient, we can implement a
command
to query the available MI versions, and switch to the
desired one.

- Volodya

On Wed, Mar 19, 2008 at 04:50:27PM +0300, Vladimir Prus
wrote:
> > > The following changes will happen:
> > > 	output ==> 
> > > 	( out-of-band-record )* [ result-record ]
"(gdb)" nl
> > > becomes:
> > > 	output ==>
> > > 		( out-of-band-record | result-record |
"(gdb)" ) nl
> > 

> The above grammar say that gdb outputs either:
> 
> 1. out-of-band record,
> 2. result record
> 3. prompt
> 
> and that any of those is followed by a newline. So, you
can
> have 100 out-of-band-records, followed by result
record, followed by
> prompt, followed by some more out-of-band records.
> 
> The 'output' nonterminal does not describe all the
output
> that gdb might produce during entire run, it describes
a single line
> that gdb might output.

Hmm, that's interesting. So you are suggesting that output
will be 
called over and over, instead of once. Am I correct?

Is it no longer possible to add a top level rule?
  ie. 
    output ==> output_line* (some terminator)

    output_line ==> 
	( out-of-band-record | result-record | "(gdb)" )
nl

I'm not sure how to rationalize about getting line after
line, with no
final response. Perhaps I need to entirely rethink what
gdb/mi is, and
how to model an api on top of it. Could you give me some
pointers?

> > OK, that's great. Please think about the request
I'm going to make, I
> > think it's very important. I think the first thing
gdb should do is
> > output a single line (a header) that tells the
version that mi is going
> > to use during this communication, and the current
versions that the 
> > particular gdb supports.
> > 
> > The more we bump the MI revisions, the more it is
going to take time for
> > front ends to continually start gdb, probing for
the best version it 
> > supports.
> > 
> > I can submit a patch for this, if you don't feel
like doing it.
> 
> We should see what the final changes will be. Probably,
we can announce
> them using the existing -list-features command and then
add a mechanism
> to enable new behaviour with a MI command.
> 
> Of course, if that proves unsufficient, we can
implement a command
> to query the available MI versions, and switch to the
desired one.

hehe. Think of it like this, xml, html, all of these other
great
languages always tell you first what the protocol you are
communicating
with is using. I just want mi to do the same thing. It's WAY
to late in
the game to call -list-features. For all you know, the user
has some
stuff in his .gdbinit that get run, and MI starts spewing
out.

I'm sure we could play some games with the command line, to
put our own
.gdbinit command to run first, but that just seems overly
complicated.

We should, at a minimum, print out the current version of mi
in a
prolouge mi statement.

Bob Rossi

On Wednesday 19 March 2008 17:05:31 Bob Rossi wrote:
> On Wed, Mar 19, 2008 at 04:50:27PM +0300, Vladimir Prus
wrote:
> > > > The following changes will happen:
> > > > 	output ==> 
> > > > 	( out-of-band-record )* [ result-record
] "(gdb)" nl
> > > > becomes:
> > > > 	output ==>
> > > > 		( out-of-band-record | result-record |
"(gdb)" ) nl
> > > 
> 
> > The above grammar say that gdb outputs either:
> > 
> > 1. out-of-band record,
> > 2. result record
> > 3. prompt
> > 
> > and that any of those is followed by a newline.
So, you can
> > have 100 out-of-band-records, followed by result
record, followed by
> > prompt, followed by some more out-of-band
records.
> > 
> > The 'output' nonterminal does not describe all the
output
> > that gdb might produce during entire run, it
describes a single line
> > that gdb might output.
> 
> Hmm, that's interesting. So you are suggesting that
output will be 
> called over and over, instead of once. Am I correct?

"called"? If you mean, printed, then yes. Which is
also the case
today -- each (gdb) is part of new 'output' nonterminal.

> Is it no longer possible to add a top level rule?
>   ie. 
>     output ==> output_line* (some terminator)
> 
>     output_line ==> 
> 	( out-of-band-record | result-record |
"(gdb)" ) nl

I probably miss something -- why would we want to add such a
top-level
rule?

> I'm not sure how to rationalize about getting line
after line, with no
> final response. Perhaps I need to entirely rethink what
gdb/mi is, and
> how to model an api on top of it. Could you give me
some pointers?

There are no pointers, I'm afraid. But basically, MI output
is a number
of lines. Frontend first parses each line individually.
Then
depending on what kind of line it was it can either:

1. For a result-record line, it declares that some command
is done,
and invokes processing relevant to that command.
2. For out-of-band-record it updates the internal state,
accordingly
to the out-of-band-record.
3. For prompt, it records that it's now OK to send new
commands to GDB
(and expect GDB to process a command immediately).

> 
> > > OK, that's great. Please think about the
request I'm going to make, I
> > > think it's very important. I think the first
thing gdb should do is
> > > output a single line (a header) that tells
the version that mi is going
> > > to use during this communication, and the
current versions that the 
> > > particular gdb supports.
> > > 
> > > The more we bump the MI revisions, the more
it is going to take time for
> > > front ends to continually start gdb, probing
for the best version it 
> > > supports.
> > > 
> > > I can submit a patch for this, if you don't
feel like doing it.
> > 
> > We should see what the final changes will be.
Probably, we can announce
> > them using the existing -list-features command and
then add a mechanism
> > to enable new behaviour with a MI command.
> > 
> > Of course, if that proves unsufficient, we can
implement a command
> > to query the available MI versions, and switch to
the desired one.
> 
> hehe. Think of it like this, xml, html, all of these
other great
> languages always tell you first what the protocol you
are communicating
> with is using. I just want mi to do the same thing.
It's WAY to late in
> the game to call -list-features. For all you know, the
user has some
> stuff in his .gdbinit that get run, and MI starts
spewing out.

Sorry, what problem is here? The MI output is designed in
such a way that
the frontend can, and should, ignore things it does not
understand. So,
if .gdbinit causes program to run, and some async
notification to be printed,
and the frontend does not understand those, well, it does
not understand those.
Things only matter if we change the meaning of some of MI
output in a backward
incompatible way.

> 
> I'm sure we could play some games with the command
line, to put our own
> .gdbinit command to run first, but that just seems
overly complicated.
> 
> We should, at a minimum, print out the current version
of mi in a
> prolouge mi statement.

What should MI2 capable frontend to is GDB reports MI7?

- Volodya

>  > Note that current thread.c implementation will
only declare a thread as done
>  > when we do -thread-info (or anything else that
calls prune_threads, so the
>  > value of =thread-exited will be limited, without
some associated work on
>  > threads layer).
> 
> I'm not sure what you mean.  If I run Gdb normally with
a multi-threaded
> application, I get:
> 
> [New Thread -1210639472 (LWP 7235)]
> 
> when a thread is created and:
> 
> [Thread -1210639472 (LWP 7235) exited]
> 
> when it is terminated.

This is historical.  In the earliest gdb thread debugging
implementations, there was no notification on thread exit, 
and gdb only removed a thread from its internal list when
prune_threads was called (which was usually on the
"info
threads" command).

More recently, we have SOME thread debugging interfaces
that
give us a thread exit notification, but we retain the
prune_threads
mechanism as insurance.  So, depending on whose threads you
are
using, you may be able to detect thread exit when it
happens, 
or you may not.

Some comments from the DSF frontend point-of-view:

> So, I propose to remove the prompt right after ^running
for the 
> sync targets.

DSF also ignores the "(gdb)", except at startup
when it uses it
to know GDB is ready.

> (*) Currently, the *stopped output does include the
token of
> the last command.  However, it's implemented in limited
way --
> if we allow any command except for -exec-interrupt in
async
> mode, the token printed for *stopped will be wrong. In
non-stop
> mode, associating *stopped with a command is just
impossible.

DSF ignores the token for all out-of-band events, so
removing
it from *stopped shouldn't be a problem.


> To simplify things, if GDB is started in MI mode, no
CLI command is allowed
> while the target is running, and -interpreter-exec is
not allowed either.

This would mean that unless all threads are stop, the user
will not be able
to use the CLI on top of MI.  It would be nice if the user
could interact
with the stopped threads using the CLI, although, I agree
with you, that
this needs to be done carefully.  

>    (**) There are two new options that a number of MI
commands may take:
>
>          --thread <id>
>
>    option specifies the id of the thread the command
should operate on.
>
>           --global
>
>    specifies that the command should operate on no
thread, but on 
>    global data.  This option is necessary to
distinguish the case where
>    the frontend has forgot to specify --thread,
assuming that the current
>    thread will be used, from the case when frontend
explicitly wants
>    to execute a command in global scope.  This clarify
of intention
>    is particularly important when the "current
thread" is running.

Does this mean that MI will still accept commands without
--thread or --global,
and interpret them to mean 'use current thread'?
For some reason, I don't like that too much.  I think the
frontend should
always use --thread or --global, so we make sure the
frontend did not really
'forget' to specify the thread. (I'm not considering any
backwards compatibly
issues here.)
But it would be nice to have a way to specifically indicate
to use  the current
thread.  Maybe a special thread id could be used ( - or *
for example).


>    - Thread commands. The -thread-info command should
be implemented (a
>    patch is already posted).
>    (**) The -thread-list-all-threads is not necessary
with the current
>    behaviour of -thread-info.
>    (**) The -thread-select command is only allowed on
the that that is
>    currently stopped.  This command should not
generally be used in
>    non-stop mode.

As suggested above, if we always use --thread or --global,
then
-thread-select could be removed -entirely.  Or, it could be
disabled in
non-stop mode, if it really should be kept for all-stop mode
(although I
don't think it does; but again, not considering backward
compatibility.)
   
>    - Program execution. The -exec-next, -exec-step,
-exec-finish, 
>    -exec-until, -exec-return, -exec-step-instruction
and 
>    -exec-next-instruction command require --thread
parameter. Also,
>    those commands resume strictly the thread that is
being stepped,
>    equivalent to "scheduler-locking on". 
>    The -exec-continue command with the --thread
parameter will resume
>    just one thread, whereas -exec-continue without a
--thread parameter
>    will resume all threads that are not presently
running.

Again, I get the feeling we should always use --thread.  But
I would
like your opinion on that.  We could have 'all' as a thread
id, or use
--global for -exec-continue all threads.


>   -> Should  varobjs be bound to only thread, or to
nothing at all.

This is an interesting question.  It brings the possibility
of supporting
both those options.  That would mean three types of variable
objects:
1- bound to a frame
2- bound to a thread
3- not bound

DSF does not make use of  variable objects, so I
don't know what would be
more useful between #2 and #3.
    

Regards,

Marc

 > >   -> Should  varobjs be bound to only
thread, or to nothing at all.
 > 
 > This is an interesting question.  It brings the
possibility of supporting
 > both those options.  That would mean three types of
variable objects:
 > 1- bound to a frame
 > 2- bound to a thread
 > 3- not bound

I think there are more than three possibilities:

1) bound to the frame in which varobj is created (*).
2) bound to the selected frame ()
3) bound to the thread in which varobj is created and 1)
4) bound to the thread in which varobj is created and 2)
5) bound to the selected thread and 1)
6) bound to the selected thread and 2)

Maybe there are more, e.g, all threads (I've not really
thought them through)

Currently only 1) works and 2) has a broken implementation.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Thursday 20 March 2008 23:53:02 Nick Roberts wrote:
>  > >   -> Should  varobjs be bound to only
thread, or to nothing at
>  > > all.
>  >
>  > This is an interesting question.  It brings the
possibility of
>  > supporting both those options.  That would mean
three types of
>  > variable objects: 1- bound to a frame
>  > 2- bound to a thread
>  > 3- not bound
>
> I think there are more than three possibilities:
>
> 1) bound to the frame in which varobj is created (*).
> 2) bound to the selected frame ()
> 3) bound to the thread in which varobj is created and
1)
> 4) bound to the thread in which varobj is created and
2)
> 5) bound to the selected thread and 1)
> 6) bound to the selected thread and 2)
>
> Maybe there are more, e.g, all threads (I've not really
thought them
> through)
>
> Currently only 1) works and 2) has a broken
implementation.

Didn't you check in a patch to make *-varobjs be found to a
thread? 
Furthermore, are (1) and (2) actually separate options? You
cannot
evaluate varobj in a frame without also specifying a
thread.

- Volodya

On Wednesday 19 March 2008 00:16:01 Vladimir Prus wrote:

> MI commands changes
> -------------------
>
>     (**) There are two new options that a number of MI
commands may
> take:
>
>           --thread <id>
>
>     option specifies the id of the thread the command
should operate
> on.
>
>            --global
>
>     specifies that the command should operate on no
thread, but on
>     global data.  This option is necessary to
distinguish the case
> where the frontend has forgot to specify --thread,
assuming that the
> current thread will be used, from the case when
frontend explicitly
> wants to execute a command in global scope.  This
clarify of
> intention is particularly important when the
"current thread" is
> running.

It seems like I have over-engineered this one. The --global
option
was meant so that we can evaluate expressions while the
target is 
running, but:

- Generally, we cannot access target memory when all threads
are
running
- GDB is full with assumptions that we have current thread
and current
frame, so even if target can access memory when all threads
is running,
gdb will still try to grab selected frame, and that will try
to grab
target's register, and that will result in error.

So, I'd like to remove the --global option. This means that
the --thread
option must be used to specify which thread to operate on,
and that
thread must be stopped.

In fact, a mechanism to evaluate expression in an arbitrary
scope 
(including global scope) might be actually good. Now,
implementing
variable tooltips via MI is impossible, as we cannot
evaluate an
expression in a given scope (defined by source line).
However, that
appears to be orthogonal issue to the non-stop mode.

- Volodya



 

 > > I think there are more than three possibilities:
 > >
 > > 1) bound to the frame in which varobj is created
(*).
 > > 2) bound to the selected frame ()
 > > 3) bound to the thread in which varobj is created
and 1)
 > > 4) bound to the thread in which varobj is created
and 2)
 > > 5) bound to the selected thread and 1)
 > > 6) bound to the selected thread and 2)
 > >
 > > Maybe there are more, e.g, all threads (I've not
really thought them
 > > through)
 > >
 > > Currently only 1) works and 2) has a broken
implementation.
 > 
 > Didn't you check in a patch to make *-varobjs be found
to a thread?

I submitted a patch earlier this year that stopped thinking
that a variable
object had gone out of scope if the thread changed but
nothing happened.

 > Furthermore, are (1) and (2) actually separate
options? You cannot
 > evaluate varobj in a frame without also specifying a
thread.

Hmm, perhaps I typed that too quickly, it looks like 3-6 are
just
multi-threaded cases of 1 and 2, so there are four in
total.

It appears that Totalview call 1) FIXED compilation scope
and 2) FLOATING
compilation scope.  Gdb calls it USE_CURRENT_FRAME and
USE_SELECTED_FRAME which
I find very confusing.  Particularly (as I've said before)
the manual mixes the
meaning of current frame with selected frame.  With
USE_SELECTED_FRAME, the
value can change without execution, e.g. after an up or
down.  It would be nice
to change these enum values to USE_FIXED_FRAME and
USE_FLOATING_FRAME.  WDYT?

In general I guess threads don't traverse the same frames so
watch expressions
wouldn't always work for all threads. I don't know how GDB
would know if they
did but I see that Totalview has something that they call a
laminated view
which views variables across threads (and processes).  In
fact their online
manual must be a good guideline for some of the non-stop
mode spec.

Also GDB loses sense of the selected frame: if you change to
a different thread
and back again you always get back to the innermost (=
current) frame.  So
that makes it difficult to get USE_SELECTED_FRAME to work in
the
multi-threaded case.



-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Friday 21 March 2008 12:48:15 Nick Roberts wrote:
>  > > I think there are more than three
possibilities:
>  > >
>  > > 1) bound to the frame in which varobj is
created (*).
>  > > 2) bound to the selected frame ()
>  > > 3) bound to the thread in which varobj is
created and 1)
>  > > 4) bound to the thread in which varobj is
created and 2)
>  > > 5) bound to the selected thread and 1)
>  > > 6) bound to the selected thread and 2)
>  > >
>  > > Maybe there are more, e.g, all threads (I've
not really thought
>  > > them through)
>  > >
>  > > Currently only 1) works and 2) has a broken
implementation.
>  >
>  > Didn't you check in a patch to make *-varobjs be
found to a
>  > thread?
>
> I submitted a patch earlier this year that stopped
thinking that a
> variable object had gone out of scope if the thread
changed but
> nothing happened.

Can you resend the current version of that patch, and I'll
take a look.

>  > Furthermore, are (1) and (2) actually separate
options? You cannot
>  > evaluate varobj in a frame without also
specifying a thread.
>
> Hmm, perhaps I typed that too quickly, it looks like
3-6 are just
> multi-threaded cases of 1 and 2, so there are four in
total.
>
> It appears that Totalview call 1) FIXED compilation
scope and 2)
> FLOATING compilation scope.  Gdb calls it
USE_CURRENT_FRAME and
> USE_SELECTED_FRAME which I find very confusing. 
Particularly (as
> I've said before) the manual mixes the meaning of
current frame with
> selected frame.  With USE_SELECTED_FRAME, the value can
change
> without execution, e.g. after an up or down.  It would
be nice to
> change these enum values to USE_FIXED_FRAME and
USE_FLOATING_FRAME. 
> WDYT?

There's also USE_SPECIFIED_FRAME, to make the whole thing
funnier. Those values are only used in the call to
varobj_create,
and struct varobj has a field named 'use_selected_frame'.
Probably
the name of field of struct varobj is fine, whereas those
USE_*
are badly named indeed. Maybe, the varobj_create interface
should
be redone to accept a frame and a "floating"
flag?

> In general I guess threads don't traverse the same
frames so watch
> expressions wouldn't always work for all threads. 

Right, so when user switches UI to a different thread, we
get to
reevaluate watches. Something like:

	-var-update --thread 2 --frame 5 

seems like appropriate solution.

> I don't know how 
> GDB would know if they did but I see that Totalview has
something
> that they call a laminated view which views variables
across threads
> (and processes).  In fact their online manual must be a
good
> guideline for some of the non-stop mode spec.
>
> Also GDB loses sense of the selected frame: if you
change to a
> different thread and back again you always get back to
the innermost
> (= current) frame.  So that makes it difficult to get
> USE_SELECTED_FRAME to work in the multi-threaded case.

I think that the syntax mentioned above will get around
that. When
GDB evaluates

	-var-update --thread 2 --frame 5 

it switches to thread (which selects frame 0) and then
immediately
selects frame 5, so by the time we evaluate expression,
we're
in the right thread and frame.

- Volodya