This is the mail archive of the gdb@sources.redhat.com 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: 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.


> > with similar for -stack-select-frame:
> > > > -> -stack-select-frame 1
> > <- *select-frame,<frame-info>,....
> > <- done
> > > > Where, yes, <frame-info> would be constructed by calling frame code.
> > > > -stack-info-frame would just be just:
> > > > -> -stack-info-frame
> > <- done,<frame-info>
> > > > The important thing is that, in both cases, the GUI is being driven by > > the select-frame event.
> > > > Cool !!
> > 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.

``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 :-)


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.


Andrew



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