[patch] MI telnet service

[Jan Kratochvil]

On Wed, 25 Jul 2012 16:12:14 +0200, Marc Khouzam wrote:
> The final goal is to allow the eclipse user to interact with
> GDB using the same command-line features as the standard
> GDB CLI,

If it should be used somehow more regularly the TCP port needs to be
reconsidered. It is already problem with gdbserver fortunately now solved by
the stdio communication option. Otherwise there is problem with security on
multi-user systems, also unique port allocation (why I introduced --once to
gdbserver) etc.


> In detail, the features Eclipse needs are:

The current problem of GDB is that its CLI is not built on top of MI (*).
Coding anything new is needlessly complicated needlessly combining all the
modes of operation together.  And instead of fixing that you go the exactly
opposite direction extending use of this CLI-and-MI mixed interface even more.

(*) MI as some RPC protocol, maybe some different and already established RPC
    protocol like D-Bus/CORBA/etc. would be better, there was a reply here MI
    clients are fine with MI:
	http://sourceware.org/ml/gdb-patches/2011-08/msg00586.html
    Such change from MI I find orthogonal to the changes discussed below.

There were some considerations to write thin CLI client on top of MI (or even
something new) just to make the internal handling of CLI vs. MI more sane.
Investment into another extension on top of the current code which does not
even provide readline functionality I do not find the right direction.


I do not think we need to keep the behavior exactly the same, minor
differences making the interface more systematic could be allowed.


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

Normal readline using ~/.gdb_history should work instead.  Omitting now about
custom 'set history filename' etc.


> - 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.

There are some Java GNU readline-like packages.  Personally I would be more
interested in simple C/C++ thin client using GNU readline on top of the MI (or
other) interface.


> - 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.

The 'complete' command seems right for it.


> - 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.

There could be additional flag sent in the result record (if MI is used).


> - 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).

Yes...


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

It could default to "no" returning the question as ^error result record
requesting some flag "yes" during next command execution.


> 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.

Do you find the proposal above worth investigation? I find the missing
readline and target-async requirement complication enough of the proposed
telnet solution that the CLI-on-top-of-MI solution working initially only for
90% of commands could be equally good enough.

Commands the CLI-on-top-of-MI interface can send as:
	-interpreter-exec console "FOO"

There is a question whether to translate known commands into proper existing
MI commands or not.  If one would want to replace MI that part would get
dropped but replacing MI I find too farsighted now that maybe some extension
of '-interpreter-exec console' would be more easy now.


> 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.

Sorry but 'screen' (or 'vnc' for Eclip=se) serves this purpose better.


Thanks,
Jan