Re: External Program interaction with Insight

Re: External Program interaction with Insight

[David Mc Kenna]

Thanks for the help.

>
>Even easier: write yourself a plugin to do it. I will be checking in a
>slightly revised plugin build architecture to deal with building plugins
>on multiple host platforms.

How does one go about writing a Plugin and is there any examples around?

Thanks,
Dave
--
http://www.iol.ie

Re: External Program interaction with Insight

[Keith Seitz]

On Mon, 25 Feb 2002, David Mc Kenna wrote:

> >Even easier: write yourself a plugin to do it. I will be checking in a
> >slightly revised plugin build architecture to deal with building plugins
> >on multiple host platforms.
>
> How does one go about writing a Plugin and is there any examples around?

Yes, there is an example plugin which compiles code, has a tcl file, and
is built for both cygwin and unix variations, although right now, only
cygwin, linux, and solaris are officially supported (haven't tried it on
anything else yet).

I haven't committed yet, because, well, it's a big change, and I would
feel more comfortable if some people looked at it.

Stay tuned.

(Now where did I put that plugin stuff? Hmm...)
Keith

External Program interaction with Insight

[David Mc Kenna]

Hi,

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  ?

Thanks for the help,
Dave McKenna


--
http://www.iol.ie

Re: External Program interaction with Insight

[Duane Ellis]

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.

Re: External Program interaction with Insight

[Keith Seitz]

On Fri, 22 Feb 2002, Duane Ellis wrote:

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

Ouch! You had to bring thaqt up! (Yes, I wrote that POS...)

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

Even easier: write yourself a plugin to do it. I will be checking in a
slightly revised plugin build architecture to deal with building plugins
on multiple host platforms.

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

Close enough. ;-) I'll be committing some changes to the memory window
interface which passes the memroy window's table into the C code and
filling it there. Gets us a good performance boost.

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

I hope you're using a safe tcl interpreter to do this, interfacing this
interpreter to insight's. It would be a little risky to allow direct
access to Insight's interp. I would love to see an interface class for
this specific purpose. (Hint, hint ;-)

> Just imagine - tunnel through a fire wall with http(s) to debug a
> problem on a remote machine... what is this world comming to.

Yeah. TCP/IP? WHat's that. We now use HTTP for everything. NFS? Bwaa haa
haa haa. Try WebDAV instead. Pretty soon we'll all have tcp ICMP!

Keith

Re: External Program interaction with Insight

[Duane Ellis]

duane > In my simulator I used Tcl/Tk's tcp/ip socket interface to simulate a
duane > serial port. When things come in from the remote socket, the 'appear'
duane > as interrupts from the serial port, you read from the 'rx-data'
duane > register and you pull bytes out.

keith> I hope you're using a safe tcl interpreter to do this, interfacing this
keith> interpreter to insight's. It would be a little risky to allow direct
keith> access to Insight's interp. 

In my case, i have a 'compiled in simulator' thus I have a single
thread of execution. As such, I can make use of insights interp :->
directly

keith> I would love to see an interface class for
       this specific purpose. (Hint, hint ;-)

The simulator has been out for quite some time, register to be an
ebookman developer (http://www.franklin.com/ebookman) and download the
sdk source code. It's all right there. You can buy an eBookman quite
cheap too (it ain't no stinking $500 pocket pc)

If you don't want to purchase the unit, You can try out the simulation
and build what we call the "gui test app" under cygwin or RH LINUX
INTEL without purchasing the product.

If you dig into the simulator source, you'll notice that the simulator
builds as a standalone application, without gdb, and builds as a
library that gets compiled into gdb. As such, the code in some places
will seem quite strange... Which answers the question: Why the hell
did he write the code that way....

Basically the simulator execute engine works like this:

At some point, gdb calls a function to tell the target to "run" and
then some function to "wait for it to finish" {ie: wait for target}.

In my 'wait for target' I have a loop that:

a) calls an "execute_some_more_opcodes()" function Every few thousand
   instructions, it returns.  {It 'comes up for air, otherwise it
   would 'drown'}

b) If things look ok, ie: No errors, breakpoints, etc, ie: it is just
   comming up for air, I monitor some other simple flags to see if I
   should stop, or not, and make some calls to ui_loop_hook(),
   notice_quit() and Tcl_DoOneEvent(). Then execute more opcodes.

the majic is "Tcl_DoOneEvent()"

Because I call that, I can simulate buttons being pressed, a touch
screen and all that sort of stuff this way.

to handle the SIO simulation, I do some small setup in tcl (ie: the
"socket -server" function), and then pass the socket handle [called a
channel-handle in tcl] to a C function. In the C function I use it as
a parameter to "Tcl_CreateChannelHandler()" along with a callback
function.

Now that the channel has a "handler" Tcl_DoOneEvent() calls my
"callback" when it discovers incomming data in the socket. In the
callback, I convert the channel handle into an "int" token for the low
level read() call.

to tx data, I do basically the same thing, and but call write()

Works quite nicely.

Sadly, I do not get true simulation (ie: serial Interrupts do not
occur at intervals based on programed baud rate). I'm not after that,
I'm after something that runs close enough...

-Duane.