Re: [Simulavr-devel] gdb interrupts

[Theodore A. Roth]

I started to implement what I described below and to turns out to be a bad 
idea. All I have to do is change the loop in gdb_continue() such that it 
check the fd. I start to appreciate your wisdom Reinhard. I'll do this 
tonight after dinner and have patch for tomorrow.

Ted

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

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