This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] MI telnet service

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]