public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Duane Ellis <duane_ellis@franklin.com>
To: insight@sources.redhat.com
Subject: Re: External Program interaction with Insight
Date: Fri, 22 Feb 2002 06:17:00 -0000	[thread overview]
Message-ID: <200202221417.JAA16150@mercury.franklin.com> (raw)
In-Reply-To: <3c76328d.7e73.0@esatclear.ie> (mckennad@esatclear.ie)


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.

  reply	other threads:[~2002-02-22 14:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22  3:59 David Mc Kenna
2002-02-22  6:17 ` Duane Ellis [this message]
2002-02-22  7:42   ` Keith Seitz
2002-02-22  9:30     ` Duane Ellis
2002-02-25  3:20 David Mc Kenna
2002-02-25 10:12 ` Keith Seitz

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=200202221417.JAA16150@mercury.franklin.com \
    --to=duane_ellis@franklin.com \
    --cc=insight@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).