From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16610 invoked by alias); 22 Feb 2002 14:17:34 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 16440 invoked from network); 22 Feb 2002 14:17:27 -0000 Received: from unknown (HELO earth-out.franklin.com) (63.88.59.82) by sources.redhat.com with SMTP; 22 Feb 2002 14:17:27 -0000 Received: from saturn.franklin.com (IDENT:root@saturn.franklin.com [192.9.200.2]) by earth-out.franklin.com (8.9.3/8.9.3) with ESMTP id JAA11799 for ; Fri, 22 Feb 2002 09:17:25 -0500 Received: from mercury.franklin.com (IDENT:root@mercury.franklin.com [192.9.200.250]) by saturn.franklin.com (8.9.3/8.9.3) with ESMTP id JAA26641 for ; Fri, 22 Feb 2002 09:17:25 -0500 Received: (from duane@localhost) by mercury.franklin.com (8.9.3/8.9.3) id JAA16150; Fri, 22 Feb 2002 09:17:26 -0500 Date: Fri, 22 Feb 2002 06:17:00 -0000 Message-Id: <200202221417.JAA16150@mercury.franklin.com> From: Duane Ellis To: insight@sources.redhat.com In-reply-to: <3c76328d.7e73.0@esatclear.ie> (mckennad@esatclear.ie) Subject: Re: External Program interaction with Insight Reply-to: duane_ellis@franklin.com References: <3c76328d.7e73.0@esatclear.ie> X-SW-Source: 2002-q1/txt/msg00141.txt.bz2 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.