Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Bob Rossi <bob@brasko.net>
Cc: Marc Khouzam <marc.khouzam@ericsson.com>, gdb@sourceware.org
Subject: Re: GDB/MI questions
Date: Thu, 19 Jan 2017 15:47:00 -0000	[thread overview]
Message-ID: <db762c0fa03cedbe315f88076899b973@polymtl.ca> (raw)
In-Reply-To: <20170119151120.GB6289@xubuntu.brasko.net>

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


  parent reply	other threads:[~2017-01-19 15:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170119031445.GA24616@xubuntu.brasko.net>
2017-01-19 14:31 ` Marc Khouzam
2017-01-19 14:52   ` Bob Rossi
2017-01-19 15:06     ` Pedro Alves
2017-01-19 15:11   ` Bob Rossi
2017-01-19 15:24     ` Marc Khouzam
2017-01-19 15:40       ` Jan Vrany
2017-01-19 16:17         ` Pedro Alves
2017-01-19 15:47     ` Simon Marchi [this message]
2017-01-19 16:03       ` Bob Rossi
2017-01-19 16:15         ` Simon Marchi
2017-01-19 16:27           ` Bob Rossi
2017-01-19 16:33             ` Pedro Alves
2017-01-19 14:43 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=db762c0fa03cedbe315f88076899b973@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=bob@brasko.net \
    --cc=gdb@sourceware.org \
    --cc=marc.khouzam@ericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox