Extending GDB to provide console over telnet

Extending GDB to provide console over telnet

[Grigory Tolstolytkin]

Hi,

I'm working on extending gdb functionality and would like to start a 
discussion since it might be useful for other people too.

The idea is to provide users an ability to remotely connect to gdb and 
perform usual debugging interaction while it is already started in 
Eclipse environment via MI interface.
This allows starting debug locally in Eclipse with connected target 
hardware, for example, and then pass debugging control to a remote user 
at some point.

Preliminary design is as following:
1. gdb is started on a local host either with Eclipse (through MI) or in 
the shell.
2. Remote users will connect to gdb using telnet via TCP.
     Additional commands need to be introduced to start corresponding 
TCP service. Namely, "start-telnet-service [port]", 
"stop-telnet-service". TCP port can be specified explicitly or hardcoded 
one (default) will be used.
3. Remote users will used standard gdb console command syntax.
4. It seems reasonable to allow many users to connect to one instance of 
gdb (Thus having individual internal interpreter for each one).
5. Debugging process under Eclipse usually generates a lot of 
information in gdb output. The key idea is to separate MI input/output 
from the remote user consoles.
     Such debugging process when two or more users are involved into 
controlling gdb might be a bit confusing. For example if users are both 
setting breakpoints their numbers will differ from what users expect and 
so on. But this is not a usual scenario to simultaneously debug the 
application. So users should know what they're doing in such a case. 
Anyway, such operations must not break gdb internals and lead to 
unpredicted results.

Any suggestions, opinions and discussions are highly welcome. I'm also 
already looking into implementation design and will provide details in 
future mails.

Regards,
Grigory

Re: Extending GDB to provide console over telnet

[Kevin Pouget]

On Thu, Sep 29, 2011 at 1:58 PM, Grigory Tolstolytkin
<gtolstolytkin@gmail.com> wrote:
> Hi,
>
> I'm working on extending gdb functionality and would like to start a
> discussion since it might be useful for other people too.
>
> The idea is to provide users an ability to remotely connect to gdb and
> perform usual debugging interaction while it is already started in Eclipse
> environment via MI interface.
> This allows starting debug locally in Eclipse with connected target
> hardware, for example, and then pass debugging control to a remote user at
> some point.
>
> Preliminary design is as following:
> 1. gdb is started on a local host either with Eclipse (through MI) or in the
> shell.
> 2. Remote users will connect to gdb using telnet via TCP.
>    Additional commands need to be introduced to start corresponding TCP
> service. Namely, "start-telnet-service [port]", "stop-telnet-service". TCP
> port can be specified explicitly or hardcoded one (default) will be used.
> 3. Remote users will used standard gdb console command syntax.
> 4. It seems reasonable to allow many users to connect to one instance of gdb
> (Thus having individual internal interpreter for each one).
> 5. Debugging process under Eclipse usually generates a lot of information in
> gdb output. The key idea is to separate MI input/output from the remote user
> consoles.
>    Such debugging process when two or more users are involved into
> controlling gdb might be a bit confusing. For example if users are both
> setting breakpoints their numbers will differ from what users expect and so
> on. But this is not a usual scenario to simultaneously debug the
> application. So users should know what they're doing in such a case. Anyway,
> such operations must not break gdb internals and lead to unpredicted
> results.
>
> Any suggestions, opinions and discussions are highly welcome. I'm also
> already looking into implementation design and will provide details in
> future mails.
>
> Regards,
> Grigory


Hello,

the idea sounds interesting, there is just one point I'm not sure to
understand exactly in your email: which interface do you want to
provide to the remote user: command-line (CLI) or MI?

from my point of view, the CLI would be very convenient, it would
allow the use of Eclipse to navigate the source code (instead of
where/list/up/down), and on the other side control the execution and
everything else from the CLI, which is just very powerful when you
know how to use it.

Actually, the best situation would be the other way around, control
GDB 'directly' so that ReadLine history/completion is also available!
(I don't thing it would work over the network, would it?)


Thanks for bringing up the idea,

Kevin

Re: Extending GDB to provide console over telnet

[Grigory Tolstolytkin]

Hi,

On 09/29/2011 04:16 PM, Kevin Pouget wrote:
> the idea sounds interesting, there is just one point I'm not sure to
> understand exactly in your email: which interface do you want to
> provide to the remote user: command-line (CLI) or MI?
>
It's CLI. I think it is more user-friendly rather than MI.
> from my point of view, the CLI would be very convenient, it would
> allow the use of Eclipse to navigate the source code (instead of
> where/list/up/down), and on the other side control the execution and
> everything else from the CLI, which is just very powerful when you
> know how to use it.
Exactly, it's one of the points.
> Actually, the best situation would be the other way around, control
> GDB 'directly' so that ReadLine history/completion is also available!
> (I don't thing it would work over the network, would it?)
As I know readline doesn't work well with sockets, but tools like rlwrap 
over telnet can be used. It's transparent to user and brings part of 
readline features like history, line editing, etc. Though gdb 
auto-completion is still a question.

> Thanks for bringing up the idea,
>
> Kevin
Regards,
Grigory

Re: Extending GDB to provide console over telnet

[Matt Rice]

On Thu, Sep 29, 2011 at 4:58 AM, Grigory Tolstolytkin
<gtolstolytkin@gmail.com> wrote:
> Hi,
>
> I'm working on extending gdb functionality and would like to start a
> discussion since it might be useful for other people too.

you can kind of do this purely with python,

below is a link to a python script which (it only writes to the
network, doesn't read..)
I use it to dump the current source location to some port every time
gdb stops (probably using some patches)...

adding this sort of stuff to .gdbinit
python from misc_gdb import twisted_gdb
# listen on port on 8007.
python twisted_gdb.start(8007)

define hook-stop
python twisted_gdb.dumpCurrentLocation()
end

in theory it'd be simple to read data from the client and
gdb.execute() them, though I believe that anything which queries the
user with a yes/no style confirmation, is going to end up with the
default.

https://gitorious.org/misc-gdb-stuff/misc-gdb-stuff/blobs/master/misc_gdb/twisted_gdb.py

Re: Extending GDB to provide console over telnet

[Jan Kratochvil]

On Thu, 29 Sep 2011 13:58:11 +0200, Grigory Tolstolytkin wrote:
> The idea is to provide users an ability to remotely connect to gdb
> and perform usual debugging interaction while it is already started
> in Eclipse environment via MI interface.

Not sure if you are aware eclipse already provides a window with CLI
interface to running GDB, via MI (also visible in an Eclipse window):
	-interpreter-exec console "the-CLI-command-you-entered"


> This allows starting debug locally in Eclipse with connected target
> hardware, for example, and then pass debugging control to a remote
> user at some point.

One can also start gdbserver (even locally):
	gdbserver --multi :10000

And use both Eclipse and GDB to attach/detach to that gdbserver using `target
extended-remote' while the inferior is still being debugged:
	(gdb) target extended-remote localhost:10000
	(gdb) set remote exec-file /home/jkratoch/workspace/entryval2/Debug/entryval2
	(gdb) b main
	(gdb) run
	(gdb) set remote kill-packet off
	(gdb) quit

I was able now to attach with Eclipse to a process started using GDB first but
Eclipse killed it during "Detach" but that may be just some Eclipse
configuration setting, I do not know Eclipse much.


Regards,
Jan