Re: [patch] MI telnet service

[Stan Shebs <stanshebs@earthlink.net>]

On 7/25/12 12:26 PM, Jan Kratochvil wrote:
> 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.

Essentially what this change is doing is making GDB itself a little more 
server-like.  It's not an accident that interpreters and ui-files are 
both objects; it's been a little surprising to me that nobody has yet 
added the multiple-port capability to take advantage of that.

>> In detail, the features Eclipse needs are:
> The current problem of GDB is that its CLI is not built on top of MI (*).

Huh, I don't recall ever hearing that diagnosis before.  It seems like 
it would be incredibly hard to migrate the CLI to be an MI veneer; not 
only is there interactive CLI behavior that MI has never had to worry 
about (because it's, well, a machine interface), but MI has generally 
limited itself to features that were known to be of use to a frontend.

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

The patch is kind of small though; it's mostly enabling latent 
capabilities, and not trying to rewrite any existing subsystems. The 
alternatives you suggest seem rather complicated by comparison.

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

Maybe nobody else thinks this, but adding an additional program into the 
Eclipse/GDB combination seems like a far more complicated approach, and 
has its own reliability issues, such as when the thin client crashes or 
hangs.

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

Not so much if it's a second person that is, say, running a diagnostic 
script, and doesn't have any use for a mirror image of all the windows.

But to pull back and take a little broader view, in a system of software 
components, I think GDB has a useful role as a server that can have 
multiple frontends, telnet-like sessions, scripted drivers, and so 
forth.  Perhaps we should decide on whether the server concept is 
plausible (maybe I'm the only one who thinks that way) or to be avoided, 
and then go from there.

Stan
stan@codesourcery.com