This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: External Program interaction with Insight
- From: Duane Ellis <duane_ellis at franklin dot com>
- To: insight at sources dot redhat dot com
- Date: Fri, 22 Feb 2002 09:17:26 -0500
- Subject: Re: External Program interaction with Insight
- References: <3c76328d.7e73.0@esatclear.ie>
- Reply-to: duane_ellis at franklin dot com
david> Is it possible to have an external programme interact with
Insight so as to use GDB to retrieve information about
registers and memory locations which can then be outputed to a
file or to the external ?
Yes, and no. Look specifically at the file "v850ice.c" in that case,
GDB uses a programitic interface to the file "necmsg.dll"
You could also look at the "win32-nat.c" file which makes use of an
another 'dll' but in a different way.
The centeral problem is that of push, or pull, or interactive.
push: gdb gives information to the other process
pull: the other process calls back into GDB to obtain
other information or to do othe things.
interactive: Both
In the above you also have to deal with "thread issues" GDB is a
single thread of execution.
Probably the easier - and slicker way is to use Tcl/Tk's built in
socket stuff. What I'm suggesting is you setup a small 'server'
application that responds to connections.
Look specifically at the tcl/tk socket stuff. You might actually
be able to do all of this in tcl/tk, maybe 100 to 200 lines of
tcl/tk code.
Remember: GDB has added some commands to tk so that you can send
arbitrary commands to GDB and capture their output. ie: capture the
output and send it back to your 'remote control program'
this is how for example the memory dump window gets it's data to
display. It just 'captures' the output of various commands an parses
them.
In my simulator I used Tcl/Tk's tcp/ip socket interface to simulate a
serial port. When things come in from the remote socket, the 'appear'
as interrupts from the serial port, you read from the 'rx-data'
register and you pull bytes out.
Likewise, when the code under simulation writes to the tx-data port
the Tcl/Tk stuff writes back to the socket.
Look at the tcl/tk command
socket -server PROC PORTNUMBER
If you want to go really far, you could make the thing look like a
mini-web server and control gdb from your browser. Probably though a
simple set of commands is all you need.
Just imagine - tunnel through a fire wall with http(s) to debug a
problem on a remote machine... what is this world comming to.
-Duane.