[Simulavr-devel] Re: Comments on simulavr

[Theodore A. Roth]

On Tue, 1 Jan 2002, address@hidden wrote:

:)address@hidden:
:)
:)> Then I run simulavr in gdbmode and avr-gdb with the demo.c program.
:)> I could load it, set a break point and step through the loop. Then I
:)> continued without a breakpoint. The program runs to into the endless
:)> loop.  Then I tried to interrupt gdb <cntrl-c>. This worked (after a
:)> while), but I couldn't run the program again.
:)
:)I believe this control-c issue is one that was resolved in the patch I
:)mailed you.
:)

I just did some digging. The problem here is gdb is catching the SIGINT
that the user initiates and ends up calling remote_interrupt(). Normally,
the signal is passed to the program being debugged via the signal
inheritance (across the fork/exec) mechanism. This doesn't work in our
case since the simulavr is not related to gdb except through the tcp
socket (which is not really a relationship at all). Thus the signal is
stopped at the border. It needs to be propagated across the socket to the
remote target. Reinhard has some ideas on how to handle events from gdb 
which show up on the sim side while the sim is processing a program.

Now just how the propagation is going to happen, I still have to figure
out. I'm not seeing gdb even trying to send anything to the target:

Sending packet: $c#63...Ack
remote_interrupt called
remote_stop called
Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) n
Remote communication error: Connection reset by peer.
(gdb) 

After the "$c#63...Ack" packet, the simulator is in an infinite loop. I 
would expect to see another packet sent to the sim when I hit C-c. Yuck. 
There might be a hook in there somewhere to allow this, but I haven't 
found it yet.

Tor's patch cleaned up handling the SIGINT on the sim side, but if gdb
doesn't pass the signal, it does us no good. Plus, passing the signal via
the socket avoids the normal signal handling mechanism. I guess we could
have the sim send a SIGINT (or other signal) to itself with kill() after
processing the signal passed thru the socket. Anyone see any flaw in that?

The main problem is in gdb, not the simulator. Once fixed, all remote
targets will experience signal joy and ultimate bliss.

Ted