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
|
