Using telnet to control a running GDB

Using telnet to control a running GDB

[Marc Khouzam]

Hi,

I saw a neat feature in another debugger that I thought would be nice for GDB.

The user could ask GDB to open a tcp port which would accept a telnet connection.
Using telnet, the user could then start a _second_ shell to the same GDB and control it.

This would help a user get a full-fledge GDB command shell, even when GDB
is being run by a frontend.

It would also allow the remote controlling of a running GDB.  Could be useful
for troubleshooting.

Such a feature wouldn't already exist, would it?

Thanks

Marc

Re: Using telnet to control a running GDB

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1308 bytes --]

On Sunday, November 28, 2010 13:27:56 Marc Khouzam wrote:
> I saw a neat feature in another debugger that I thought would be nice for
> GDB.
> 
> The user could ask GDB to open a tcp port which would accept a telnet
> connection. Using telnet, the user could then start a _second_ shell to
> the same GDB and control it.
> 
> This would help a user get a full-fledge GDB command shell, even when GDB
> is being run by a frontend.
> 
> It would also allow the remote controlling of a running GDB.  Could be
> useful for troubleshooting.
> 
> Such a feature wouldn't already exist, would it?

your description is a bit vague as to what you want this to do exactly.  my 
understanding of gdb is that it isnt designed for multiple control threads.  
plus, it'd be a bit confusing for one gdb controlling a process and to have 
two different interfaces attempting to change the execution flow.

ive seen gdb monitors that accepted telnet sessions as well as gdb connections 
simultaneously, but the telnet sessions were more for maintenance than actual 
gdb type behavior.  in other words, you had a dedicated device running a 
dedicated monitor that controlled some other processor (e.g. a BDI or PEEDI 
ICE).

it'd help if you described with more details and actual examples.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Using telnet to control a running GDB

[Jan Kratochvil]

On Sun, 28 Nov 2010 19:27:56 +0100, Marc Khouzam wrote:
> The user could ask GDB to open a tcp port which would accept a telnet connection.
> Using telnet, the user could then start a _second_ shell to the same GDB and control it.
> 
> This would help a user get a full-fledge GDB command shell, even when GDB
> is being run by a frontend.

Such shell is present there, isn't it?  You have even provided a fix for it:
	https://bugs.eclipse.org/bugs/show_bug.cgi?id=285320

(eclipse-cdt-6.0.2-5.fc13.x86_64, a bit old, sorry)  Click on Debug window,
line with "gdb" then I can type CLI GDB commands into the window "Console".
It does not print the GDB prompt there but it works.  GDB gets this command
via MI:
	40-interpreter-exec console "print 1+1"N (N=\n)


> It would also allow the remote controlling of a running GDB.  Could be useful
> for troubleshooting.

When GDB is really running (and not waiting on external event) it is not
thread safe in general to do anything else in that moment.

In async (+ non-stop) mode you enabled to be implemented it should never do
such operation any noticeable time; if it does, GDB should be fixed (either
for missing async or for performance).

So it is fully on the front end to provide asynchronous "Console" window
interface, isn't it?


Thanks,
Jan

RE: Using telnet to control a running GDB

[Marc Khouzam]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] 
> Sent: Sunday, November 28, 2010 9:56 PM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: Using telnet to control a running GDB
> 
> On Sun, 28 Nov 2010 19:27:56 +0100, Marc Khouzam wrote:
> > The user could ask GDB to open a tcp port which would 
> accept a telnet connection.
> > Using telnet, the user could then start a _second_ shell to 
> the same GDB and control it.
> > 
> > This would help a user get a full-fledge GDB command shell, 
> even when GDB
> > is being run by a frontend.
> 
> Such shell is present there, isn't it?  You have even 
> provided a fix for it:
> 	https://bugs.eclipse.org/bugs/show_bug.cgi?id=285320

:-)

> (eclipse-cdt-6.0.2-5.fc13.x86_64, a bit old, sorry)  Click on 
> Debug window,
> line with "gdb" then I can type CLI GDB commands into the 
> window "Console".
> It does not print the GDB prompt there but it works.  GDB 
> gets this command
> via MI:
> 	40-interpreter-exec console "print 1+1"N (N=\n)

That console is also missing
1- command completion, which we may be able to do using GDB's
'complete' command (thanks Dan for mentioning the command)
2- command history, which will require (I think) to re-implement
some of the readline (is that what it is called?) functionality :-(

Until that is done, having a telnet session to GDB (if the 
feature already existed) would have been a workaround for the user.
Although, it would probably make the frontend out-of-sync, and
it would be harder to fix for the frontend, since it wouldn't
be controlling the external GDB shell... Sigh...
Maybe this wasn't such a good idea, from the frontend point-of-view.
 
> > It would also allow the remote controlling of a running 
> GDB.  Could be useful
> > for troubleshooting.
> 
> When GDB is really running (and not waiting on external 
> event) it is not
> thread safe in general to do anything else in that moment.
> 
> In async (+ non-stop) mode you enabled to be implemented it 
> should never do
> such operation any noticeable time; if it does, GDB should be 
> fixed (either
> for missing async or for performance).

I was not thinking of an asynchronous access.  Simply a
'duplicate' shell that would behave like the master one.
If the master has GDB running and not accepting commands, 
then the slave(s) would do the same.

A simple example would be that I setup a debug session using
GDB and things are not behaving as I expect.  I call someone
to help me look at it.  That person would be able to remotely
connect to my running instance of GDB and start controlling it,
instead of tell me to 'try this command', 'try that command'.

I didn't really think of all the implications of this, like
if the master shell would show the commands given by the slave(s),
for example.  But I was curious to know if the feature existed
or was ever considered (or rejected :-))

> So it is fully on the front end to provide asynchronous 
> "Console" window interface, isn't it?

In the frontend, we try to mimic the exact user experience
provided by the standard GDB shell.  But we are still
missing features, and need to duplicate much of the
functionality ourselves.

Thanks

marc

Re: Using telnet to control a running GDB

[Jan Kratochvil]

On Mon, 29 Nov 2010 16:24:32 +0100, Marc Khouzam wrote:
> Until that is done, having a telnet session to GDB (if the 
> feature already existed) would have been a workaround for the user.

GDB is feature-complete for such "independent session".

If there is a problem implementing it to Eclipse you can just create
a "tee"-like intermediate server:

Eclipse <-MI-> new-server <-MI-> gdb
                    |
console <-MI-or-CLI-+
                    |
console <-MI-or-CLI-/

the point is every command sent by new-server -MI-> gdb should finish
immediately due to async/non-stop so any command from "console" can be sent by
new-server -MI-> gdb without any delay.

[ You should have more experience with async/non-stop/MI than me, though.  ]


> Although, it would probably make the frontend out-of-sync,

This happens even with current Eclipse GDB Console, for example by modifying
a variable displayed in the Variables window.


> A simple example would be that I setup a debug session using
> GDB and things are not behaving as I expect.  I call someone
> to help me look at it.  That person would be able to remotely
> connect to my running instance of GDB and start controlling it,
> instead of tell me to 'try this command', 'try that command'.

TBH isn't a VNC session to the full Eclipse GUI more suitable?


Thanks,
Jan

RE: Using telnet to control a running GDB

[Marc Khouzam]

> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] 
> Sent: Monday, November 29, 2010 1:55 PM
> To: Marc Khouzam
> Cc: 'gdb@sourceware.org'
> Subject: Re: Using telnet to control a running GDB
> 
> On Mon, 29 Nov 2010 16:24:32 +0100, Marc Khouzam wrote:
> > Until that is done, having a telnet session to GDB (if the 
> > feature already existed) would have been a workaround for the user.
> 
> GDB is feature-complete for such "independent session".

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?

> If there is a problem implementing it to Eclipse you can just create
> a "tee"-like intermediate server:
> 
> Eclipse <-MI-> new-server <-MI-> gdb
>                     |
> console <-MI-or-CLI-+
>                     |
> console <-MI-or-CLI-/

That is interesting.  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.

> the point is every command sent by new-server -MI-> gdb should finish
> immediately due to async/non-stop so any command from 
> "console" can be sent by
> new-server -MI-> gdb without any delay.
> 
> [ You should have more experience with async/non-stop/MI than 
> me, though.  ]

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

> > Although, it would probably make the frontend out-of-sync,
> 
> This happens even with current Eclipse GDB Console, for 
> example by modifying
> a variable displayed in the Variables window.

The changes done in Eclipse are pushed to GDB.  However, it is
the reverse that causes a problem.  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.

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.

> > A simple example would be that I setup a debug session using
> > GDB and things are not behaving as I expect.  I call someone
> > to help me look at it.  That person would be able to remotely
> > connect to my running instance of GDB and start controlling it,
> > instead of tell me to 'try this command', 'try that command'.
> 
> TBH isn't a VNC session to the full Eclipse GUI more suitable?

Very true.  A telnet session is just so easy to use, with nothing
to setup.  Like I said, I saw it in another debugger, which is
why I was asking the question.

But maybe the feature does not add much...

Marc

Re: Using telnet to control a running GDB

[Jan Kratochvil]

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

Re: Using telnet to control a running GDB

[Tom Tromey]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Marc> I saw a neat feature in another debugger that I thought would be
Marc> nice for GDB.

Marc> The user could ask GDB to open a tcp port which would accept a
Marc> telnet connection.  Using telnet, the user could then start a
Marc> _second_ shell to the same GDB and control it.

Marc> Such a feature wouldn't already exist, would it?

More or less:

http://blogs.gnome.org/alexl/2009/10/09/gdb-over-irc/

Tom

Re: Using telnet to control a running GDB

[Tom Tromey]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Jan> [ You should have more experience with async/non-stop/MI than 
Jan> me, though.  ]

Marc> We don't always use aync/non-stop in Eclipse.  It is up to the
Marc> user to decide.

I am curious to know why Eclipse works this way.

Tom

Re: Using telnet to control a running GDB

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

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

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

I don't think I understand that.

It seems to me that if we want to support a GUI that also has a
gdb-cli-like console, then commands entered at that console should
report both MI and CLI output, so that the GUI can parse the MI
notifications and update other parts of the user interface.

I assume this doesn't work today, but I don't see why it couldn't be
implemented.

I suppose an alternate idea would be to only have MI output and require
the GUI to format it into the console window itself.  This seems
somewhat less nice since it means duplicating the formatting code.

Tom

RE: Using telnet to control a running GDB

[Marc Khouzam]

From: Tom Tromey [tromey@redhat.com]
>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Jan> [ You should have more experience with async/non-stop/MI than
Jan> me, though.  ]

Marc> We don't always use aync/non-stop in Eclipse.  It is up to the
Marc> user to decide.

> I am curious to know why Eclipse works this way.

From the discussions I have seen about non-stop, it seems some user
feel the all-stop mode is more intuitive, while others prefer non-stop.

I personally think non-stop is the most obvious one, but it may have
to do with my telecom background.

Therefore, we let the user choose which mode they prefer.

Also, we still support GDB 6.6, 6.7 and 6.8, which don't have
non-stop at all.  Finally, the all-stop mode was what users of Eclispe
and GDB were accustomed to until GDB 7.0, so they may find it annoying 
if Eclipse forced them to use non-stop (kind of like if GDB decided to remove all-stop).

Marc

Re: Using telnet to control a running GDB

[Tom Tromey]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Jan> [ You should have more experience with async/non-stop/MI than
Jan> me, though.  ]

Marc> We don't always use aync/non-stop in Eclipse.  It is up to the
Marc> user to decide.

Tom> I am curious to know why Eclipse works this way.

Marc> From the discussions I have seen about non-stop, it seems some
Marc> user feel the all-stop mode is more intuitive, while others prefer
Marc> non-stop.

Ok, thanks.

I am usually confused about all the modes that gdb supports.  Your
explanation of non-stop makes sense to me.  This has user-visible
effects and could be "weird", especially if you are used to all-stop.

And, I imagine that the reason for not always using async is just that
it isn't universally supported -- you want to handle older GDB versions,
and even with current GDB I suppose it is not supported by all targets.
Is that the situation?

TBH I think it would be better if we could remove some modes.  For
example, if we could make target-async either the default, or enabled
automatically if the user uses some async command.

Tom

Re: Using telnet to control a running GDB

[Tristan Gingold]

On Dec 7, 2010, at 4:51 PM, Tom Tromey wrote:
> TBH I think it would be better if we could remove some modes.  For
> example, if we could make target-async either the default, or enabled
> automatically if the user uses some async command.

Just keep in mind that a lot of probes only implement the minimal set of commands.  So if we remove some modes (which I think is a good idea), we need to keep the veteran sync/all-stop mode.

Tristan.

RE: Using telnet to control a running GDB

[Marc Khouzam]

 

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com] 
> Sent: Tuesday, December 07, 2010 10:51 AM
> To: Marc Khouzam
> Cc: 'Jan Kratochvil'; 'gdb@sourceware.org'
> Subject: Re: Using telnet to control a running GDB
> 
> >>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:
> 
> Jan> [ You should have more experience with async/non-stop/MI than
> Jan> me, though.  ]
> 
> Marc> We don't always use aync/non-stop in Eclipse.  It is up to the
> Marc> user to decide.
> 
> Tom> I am curious to know why Eclipse works this way.
> 
> Marc> From the discussions I have seen about non-stop, it seems some
> Marc> user feel the all-stop mode is more intuitive, while 
> others prefer
> Marc> non-stop.
> 
> Ok, thanks.
> 
> I am usually confused about all the modes that gdb supports.  Your
> explanation of non-stop makes sense to me.  This has user-visible
> effects and could be "weird", especially if you are used to all-stop.
> 
> And, I imagine that the reason for not always using async is just that
> it isn't universally supported -- you want to handle older 
> GDB versions,
> and even with current GDB I suppose it is not supported by 
> all targets.
> Is that the situation?

Yes, we try to provide an Eclipse frontend for different people,
and some of them only have access to an older GDB for their target.

> 
> TBH I think it would be better if we could remove some modes.  For
> example, if we could make target-async either the default, or enabled
> automatically if the user uses some async command.
> 
> Tom
>