This is the mail archive of the gdb@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: Using telnet to control a running GDB


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


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