Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Marc Khouzam <marc.khouzam@ericsson.com>
To: "'Jan Kratochvil'" <jan.kratochvil@redhat.com>
Cc: "'gdb@sourceware.org'" <gdb@sourceware.org>
Subject: RE: Using telnet to control a running GDB
Date: Mon, 29 Nov 2010 20:00:00 -0000	[thread overview]
Message-ID: <F7CE05678329534C957159168FA70DEC572E79C924@EUSAACMS0703.eamcs.ericsson.se> (raw)
In-Reply-To: <20101129185524.GA13721@host0.dyn.jankratochvil.net>

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


  reply	other threads:[~2010-11-29 20:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28 18:28 Marc Khouzam
2010-11-28 22:40 ` Mike Frysinger
2010-11-29  2:56 ` Jan Kratochvil
2010-11-29 15:24   ` Marc Khouzam
2010-11-29 18:55     ` Jan Kratochvil
2010-11-29 20:00       ` Marc Khouzam [this message]
2010-11-29 20:39         ` Jan Kratochvil
2010-12-06 18:40           ` Tom Tromey
2010-12-06 18:36         ` Tom Tromey
2010-12-07  2:50           ` Marc Khouzam
2010-12-07 15:51             ` Tom Tromey
2010-12-07 16:13               ` Tristan Gingold
2010-12-07 17:14               ` Marc Khouzam
2010-11-29 21:10 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F7CE05678329534C957159168FA70DEC572E79C924@EUSAACMS0703.eamcs.ericsson.se \
    --to=marc.khouzam@ericsson.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox