Re: Using telnet to control a running GDB

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 29 Nov 2010 21:00:34 +0100, Marc Khouzam wrote:
> I'm not disagreeing, but I'm not clear what you mean.
> Do you mean that GDB has a feature to allow for indepent sessions?

It is the same as event-driven vs. threading model.

The event-driven model is for example implemented by Gnome/GLib applications.
There is a mainloop waiting for events, any event is immediately processed,
further actions are remembered (like GDB continuations) and execution always
immediately drops back to the mainloop.

With threading model each action creates new thread and such thread waits and
tracks that one specific action until it completes.

This two approach are equivalent, they just require different coding approach.
GDB async represents the event-driven one, you request "independent sessions"
representing the threading model.  The threading model is more intuitive for
coding but it is more resources demanding.

(gdb) continue &
(gdb) print 1 + 2 # this command may come from an "independent session"


> However, command-history, using arrow-up/down, is not an actual CLI command,
> so I wouldn't be able to reproduce that feature in the Eclipse console.

command-history has no place in a communication protocol.  It is
a user-interface local feature.

You can implement readline-like feature in Eclipse console by some library
like JLine as a JNI interface to arch-specific real GNU readline would be
probably a complication for Eclipse distribution.


> We don't always use aync/non-stop in Eclipse.  It is up to the
> user to decide.  But that is not a problem because the eclipse
> GDB console, should not accept commands when GDB is busy (just
> like GDB's shell does not accept commands).

The "indepent session" would not be possible without async/non-stop.


> If the user modifies a variable in the console, there is no event to tell
> the frontend that something changed and should be updated in the variables
> view.  What we do in eclipse, is that we parse all the commands sent to the
> console, and we try to figure out if such a command will require an update
> in the eclipse views.

That is not nice but I understand there is currently no other way.


> If the console was outside eclipse (like the telnet session,
> I'm mentioning), eclipse may not be able to catch the commands
> from that telnet to be able to parse them, and would then
> fall out-of-sync with GDB.

MI should rather notify changes done over MI when talking about some right way
to do it.



Thanks,
Jan