Re: [patch] MI telnet service

Stan Shebs
2012-07-26T00:02:23Z

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