This is the mail archive of the gdb-patches@sourceware.org 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 Thu, 26 Jul 2012 02:02:07 +0200, Stan Shebs wrote:
> Essentially what this change is doing is making GDB itself a little
> more server-like.

I find this design fine, I am not against it.

But from the implementation point of view it mixes together with the long-term
pain of mixed CLI and MI processing.  The goal is to produced only raw data
(like MI does) by current GDB code and to have a completely different code
formatting the MI data as CLI (the way Eclipse formats the MI data as GUI)

------------------------------------------------------------------------------
If it is not clear why the CLI and MI processing mix is a pain I can
illustrate on (but there are many such cases in GDB)
	http://sourceware.org/ml/gdb-patches/2011-09/msg00558.html
as the code handles 7 modes of "set print entry-values" setting (it has to).
But additionally to it the same code has to handle both proper readable output
in CLI mode and proper MI output where the MI output is done in two passes.
In reality one has to put all the combinations into the testsuite as otherwise
a minor edit will break some of the 21 modes each lines of code runs in.
------------------------------------------------------------------------------

Formally the patterns of separating of the code I have Googled out as:
	http://en.wikipedia.org/wiki/Separation_of_concerns
specifically here proposing roughly current GDB to be 'model', its MI to be
'adapter' and new-CLI-on-top-of-MI client + Eclipse to be 'view':
	http://en.wikipedia.org/wiki/Model-view-adapter

This way the interface of GDB will be only MI which can be easily multiplexed
into multiple views. One of the view to be still Eclipse and other views to be
each CLI (also easily featuring GNU readline).


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

If there is some way how to implement multiple GNU readlines it may be
reconsidered but I find CLI without readline to be unusable.


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

See above.

> not only is there interactive CLI behavior

That's the problem, mixing UI with GDB logic. Also because usually different
types of developers maintain each kind of code, which is unfortunately
currently mixed together.


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

Yes, MI would need to be extended many times so that the CLI-on-top-of-MI
interface no longer has to use the '-interpreter-exec console ...' hack.


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

(1) I do not see that Eclipse should run another program, it is up to Eclipse
    which way it would be implemented there.  IIUC Eclipse would use GNU
    readline classes, with no new process involved.
(2) New program (*) is better, when it means reducing the codebase of the
    original program (=removing CLI from current GDB codebase; in the future).

(*) I do not say CLI-on-top-of-MI client needs to really run as a separate
    UNIX process, but it should be possible to run it that way.  In reality it
    may be something like just linkage with libgdb.a.


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

I agree.  Just GDB should not directly interface by CLI, this has been already
a pain and it is no longer well extensible.  This also currently means that
any '--More--' prompt will stop all the other connected clients, so
a forgotten '--More--' prompt in the lab will prevent the designer to connect
to the same GDB from home anyway.


I will hopefully get to coding some very basic CLI-on-top-of-MI client to see
how practically usable it is.


Thanks,
Jan


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