RE: Using telnet to control a running GDB

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

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