This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: How does GDB/MI give the current frame
- From: "Alain Magloire" <alain at qnx dot com>
- To: cagney at gnu dot org (Andrew Cagney)
- Cc: nickrob at gnu dot org (Nick Roberts), alain at qnx dot com (Alain Magloire), drow at false dot org (Daniel Jacobowitz), gdb at sources dot redhat dot com
- Date: Thu, 8 Jul 2004 19:07:22 -0400 (EDT)
- Subject: Re: How does GDB/MI give the current frame
>
> > > > For the CLI, something like this:
> > > >
> > > > -> -interpreter cli "up"
> > > > <- ~"info on new frame..."
> > > > <- *select-frame,<frame-info>...
> > > > <- done
>
> Note that the interpreter case is key, it lets the GUI respond to
> operations on the command line.
>
Absolutely!!
> > > One thing:
> > >
> > > -thread-select 2
> > > ^done,...
> > > -stack-select-frame 3
> > > ^done
> > > -thread-select 1
> > > ^done,..
> > > -thread-select 2
> > > ^done,..
> > >
> > > If you would do "-stack-info-frame" now, you would notice that current
> > > stackframe for thread 2 is not longer frame 3 but frame 0 !!
> > > It this case would not it be appropriate to fire a "*select-frame" event.
> >
> > There would still be problems with displaying the values of variables.
> > Neither variable objects or the CLI command, display, seem to take
> > notice of the thread number.
>
Nic, are you using the -var-obj for variables, in theory they
have the context i.e. should be thread aware ?
> ``bug'' in current MI protocol. How would something like:
>
> -thread 2 -<something else>
> ^done
> -thread 2 -frame 3 -<something else>
> -frame 3 -<something else>
> ^done
>
> grab you? ``-thread'' and ``-frame'' select the thread/frame for
> _just_ the period of that command. They would not alter the CLI's
> selected thread/frame (the implementation would for the moment need to
> be a crock but thats a separate problem :-).
>
> This would let the GUI manipulate frames independant of the CLI.
>
> > Second thing:
> > Playing with MI, I've notice in between -var-update|-var-delete|etc ..
> > operation the frame selection level was reset to 0, failing the other operations
> > that was still assuming a certain frame level.
> > Now is this an appropriate behaviour? or a bug? if it is appropriate should
> > client recall -stack-select-frame XX all the time to make sure things are ok
>
> ``bug''. Actually major screwup in how GDB models threads (as in it
> doesn't really :-)
>
8-) ok.
> > How about to put the thread-id part ot the event ?
>
> So the event would be ``selected changed'' and generated when both
> switching threads and frames? If it is useful, ok.
>
If you are asking if we would want an event for thread selection
the same as for frame selection ... The answer is a strong "Yes".
Our problems is coordinating the mix of CLI and UI driven actions
so things are in sync. So if the user select a new thread via
the command line, variables and all othe related views should be updated.
The hard lesson learn from the last CDT/Debug release, is that the
command prompt will stay and the users(allthough not a majority) that
wanted this feature ... are __very__ vocal.