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


 > That's almost the whole idea.  The -interpreter-exec command provides 
 > two mechanism to the GUI/client:
 > 
 > - the ability to access GDB's `console' vis:
 > 	-> -interpreter cli "up"
 > 	<- ~"info on new frame..."
 > 	<- done
 > 
 > - the ability to notify the GUI of console sideeffects vis:
 > 	<- *select-frame,<frame-info>...

That sounds like a third interface. This is an elegant approach but assumes
that someone will implement the notification for every CLI command that has
side effects. This seems unlikely in the current circumstances

 >  > In Emacs, I will run commands from the console with
 >  > "-interpreter-exec console" and check the status of gdb with a set of MI
 >  > commands run behind the users back. I imagine a lot of others will do the
 >  > same, so please don't change this.
 > 
 > Wouldn't these polling commands need to be run behind the users back 
 > after every CLI command?  By monitoring these events, the GUI can avoid 
 > polling except when needed.

Yes, so I guess it will be slower. It just seems a realistic starting point.
It would only need a handful of MI commands to give the rough status of GDB:

-var-update
-break-list
-stack-list-locals
-stack-list-frames
-stack-info-frame  (not implemented yet)

The MI output on the "-interpreter-exec console" command could be added later
if wished. I think it would need to be done in a co-ordinated fashion not
piecemeal, however.

Nick


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