RE: [patch] MI telnet service

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jan Kratochvil
> Sent: Wednesday, July 25, 2012 9:02 AM
> To: Abid, Hafiz
> Cc: gdb-patches@sourceware.org
> Subject: Re: [patch] MI telnet service

> Have you talked to Eclipse maintainers why they do not 
> provide separate
> console?  In fact they do, I find it more fits there.  If 
> communication with
> Eclipse developers has failed GDB can implement it, but I 
> find it more as Eclipse workaround.

I understand your point-of-view.  There are advantages to
having this feature in GDB instead of Eclipse though.
The final goal is to allow the eclipse user to interact with
GDB using the same command-line features as the standard
GDB CLI, and to keep Eclipse up-to-date with respect
to the changes made through this console.  The latter point
is being addressed separately by adding more MI events.
This telnet patch attempts to make it easier for Eclipse
to give a full CLI to the user directly in Eclipse. 

Conceptually one can argue that "interacting directly with GDB 
should be handled by GDB itself" and not have go through another
layer pretending to be GDB.  Furthermore, something feels wrong
and limiting about providing a CLI look & feel while going through
the MI channel used by Eclipse.

In detail, the features Eclipse needs are:

- Command-history: This could be managed in Eclipse, but would
  require more work to achieve the same flexibility and richness
  that GDB provides.

- Readline features: This is more complicated.  We could implement
  the same readline features directly in Eclipse (there is probably
  a package we could use to get this working) but re-using GDB's
  existing feature seems a simpler path to take.  Also, and I'm
  not sure of this, it may be even more effort to get this to
  work for Windows also, while GDB provides all this already.

- Command-completion: This could be achieved using GDB's 'complete'
  command.  The look & feel of this feature would probably not be 
  exactly like in GDB which may be an annoyance to the user.  And 
  respecting GDB preferences (if there are some that affect completion)
  will require some extra handling.

- Repeat last command: I don't believe this can be done in Eclipse
  without GDB's help, and I don't know of a way to ask GDB if a
  command should be repeated or not.

- Prompt: GDB does some smart handling of the prompt, which would have
  to be replicated in Eclipse (or at least a poor-man's version).

- Queries: Because Eclipse uses MI, GDB handles queries differently
  and such queries are being automatically defaulted instead of
  being presented to the user.

There are probably a couple of more that slip my mind right now.

We felt that the most efficient way to get this feature was to
re-use as much of GDB's features as possible, which explains why
this telnet approach is being proposed.

Beyond the Eclipse use-case, I personally feel that this
telnet feature adds value to GDB for other situations.
For example, a designer could remote connect to a running
GDB that was setup in the lab, or one could continue a debug
session after having gone home.  Not world-changing, but
valuable nonetheless IMHO.

Your comments are most welcomed.

Thanks

Marc