GDB/MI questions

Simon Marchi simon.marchi@polymtl.ca
Thu Jan 19 15:47:00 GMT 2017


On 2017-01-19 10:11, Bob Rossi wrote:
> I'm just trying to provide the same functionality I did when I was 
> using
> annotations. This was one of the noted differences.
> 
> Since the MI differs in this area, I've done as you suggested and
> that works well. I guess I'll see if there are any downsides here.
> 
> Thanks,
> Bob Rossi

 From experience (I'd like to be proven wrong), it will be very difficult 
to accurately re-create the gdb console "experience" when using MI.  The 
commands that should or should not repeat is just one example.  Consider 
history, tab completion, readline bindings (e.g. ctrl-R), pagination, 
etc.  How does that work with the MI version of cgdb?

If I understand correctly how annotations work, when the user types, 
they are interacting directly with gdb.  So when they press tab to get a 
completion, it's handled by gdb.  With MI, the user interacts with the 
front-end, which in turns talk to gdb.  So the front-end would have to 
re-implement all those features.

This is why gdb has this "new-ui" command that Pedro mentioned.  Instead 
of trying to emulate a gdb console, the front-end can start GDB in 
standard console mode (redirecting its i/o to an embedded terminal 
emulator) and open a channel on the side with new-ui for MI commands.  
This way, when using the console, the user interacts directly with gdb, 
and gets the real console experience.

 From what I know, cgdb in entirely controlled by command line, but 
displays some additional info along with the source code.  For example, 
an arrow at the execution point, and red line numbers where there are 
breakpoints.  If you implemented it using the new-ui scheme, cgdb would 
just have to listen to specific events, like *stopped or 
=breakpoint-created to update its UI.  Actually, even if you implement 
the console using "-interpreter-exec-console", you'll probably have to 
listen to those events, unless you want to parse an interpret the gdb 
commands the user types (which doesn't sound like a good idea).  And 
since your UI is "read-only" (the user doesn't do run control from the 
UI), I think you wouldn't even need to send any MI command...  In the 
end it's probably much easier (although there are some pitfalls to be 
aware of), since you offload all the user input management to gdb.

Simon



More information about the Gdb mailing list