Re: [Simulavr-devel] gdb interrupts

[Theodore A. Roth]

Alright, I've figured this out.

When the user hits C-c from the gdb command line, gdb will send a byte 
(0x03) down the line. It is _not_ wrapped by the "$...#cc", thus you don't 
see a packet sent (no packet is sent!). But gdb did tell us that it sent 
the interrupt. So... gdb is doing the right thing. We need to modify 
gdbserver.c as Reinhard suggested to be able to handle processing 
unexpected events.

Right now, simulavr will catch the 0x03 byte (if it's not in executing
insn's) and reply with a "S04" packet. Of course, this is wrong.

Here's what I'm going to try. After simulavr executes an instruction, have 
it do a nonblocking read on the socket fd. If data is ready, it will have 
to process it and handle it appropriately then maybe go back to executing 
instructions.

I'm thinking about adding another element to the core struct which would
be a hook that gdbserver.c will install a function into to perform the
operation. This way another interface could hook into the core if
gdbserver.c is not being used and the core needs to know nothing about it
except to call the function if the pointer is not NULL. If the hook
function returns non-zero, then simulavr should break out of the execution
loop.

Comments?

Ted

On Tue, 1 Jan 2002, Theodore A. Roth wrote:

:)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
:)
:)
:)
:)_______________________________________________
:)Simulavr-devel mailing list
:)address@hidden
:)http://mail.freesoftware.fsf.org/mailman/listinfo/simulavr-devel
:)