* External Program interaction with Insight @ 2002-02-22 3:59 David Mc Kenna 2002-02-22 6:17 ` Duane Ellis 0 siblings, 1 reply; 6+ messages in thread From: David Mc Kenna @ 2002-02-22 3:59 UTC (permalink / raw) To: insight 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: External Program interaction with Insight 2002-02-22 3:59 External Program interaction with Insight David Mc Kenna @ 2002-02-22 6:17 ` Duane Ellis 2002-02-22 7:42 ` Keith Seitz 0 siblings, 1 reply; 6+ messages in thread From: Duane Ellis @ 2002-02-22 6:17 UTC (permalink / raw) To: insight 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: External Program interaction with Insight 2002-02-22 6:17 ` Duane Ellis @ 2002-02-22 7:42 ` Keith Seitz 2002-02-22 9:30 ` Duane Ellis 0 siblings, 1 reply; 6+ messages in thread From: Keith Seitz @ 2002-02-22 7:42 UTC (permalink / raw) To: mckennad; +Cc: Insight Maling List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: External Program interaction with Insight 2002-02-22 7:42 ` Keith Seitz @ 2002-02-22 9:30 ` Duane Ellis 0 siblings, 0 replies; 6+ messages in thread From: Duane Ellis @ 2002-02-22 9:30 UTC (permalink / raw) To: insight 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: External Program interaction with Insight
@ 2002-02-25 3:20 David Mc Kenna
2002-02-25 10:12 ` Keith Seitz
0 siblings, 1 reply; 6+ messages in thread
From: David Mc Kenna @ 2002-02-25 3:20 UTC (permalink / raw)
To: Keith Seitz, mckennad, Insight Maling List
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: External Program interaction with Insight 2002-02-25 3:20 David Mc Kenna @ 2002-02-25 10:12 ` Keith Seitz 0 siblings, 0 replies; 6+ messages in thread From: Keith Seitz @ 2002-02-25 10:12 UTC (permalink / raw) To: David Mc Kenna; +Cc: Insight Maling List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-02-25 18:12 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-02-22 3:59 External Program interaction with Insight David Mc Kenna 2002-02-22 6:17 ` Duane Ellis 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
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).