This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI non-stop mode spec


On Thursday 20 March 2008 20:58:20 Marc Khouzam wrote:
> 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.

Ok, good.

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

Excellent.

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

Yes, my biggest concern is that if we enable all CLI commands, user
can easily messup everything. OTOH, maybe we should just allow the
frontend to recover:

1. GDB will accept commands at all times.
2. I have a patch for -thread-info to report which threads are running,
and which are stopped. I might also add information about which command
"step/continue/finish/etc" is being run in each thread.

Then, even if user's CLI command does something bad, we should be able
to see the state of the target, stop all running threads, and get 
situation under control.

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

I'm not actually sure what's the best way here. On one hand, allowing
implicit current thread provides some backward compatibility. However,
it seems that converting either CDT or KDevelop should be relatively
easy. 

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

Yes, removing -thread-select would be very nice.

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

I think that for -exec-continue, we are relatively safe, as the
current thread is relatively unimportant in its operation -- it 
basically work the same way no matter what thread is current.

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

I don't know either. The purpose of @ varobj appears to be for 
expressions that have to be reevaluated in the current scope -- the
"watch" functionality. But the meaning of current scope is a question. 
I'd presume that frontend would keep the current thread (from user 
point of view, just whatever is selected in thread list) and inside 
that the current frame, and when user selects either different thread
or different frame, watch should be updated. This suggests that @ 
varobjs should not be bound to thread. 

It should be noted that for  @ varobj to work as described, each change
of user-visible current thread/frame should result in -var-update 
command for each @ varobj, since -var-update * updates all varobj, and 
this might be slow. Maybe, we need "-var-update @" that will update
all @ varobjs.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]