Re: [Simulavr-devel] gdb interrupt patch.

[Theodore A. Roth]

On Wed, 2 Jan 2002, address@hidden wrote:

:)I have test the patch now and it is as I expect that it is.
:)It is not a good idea to sent SIGILL to gdb if the 0x03 is detected.
:)The loop gets aborted, but not because of 0x03, but because of the
:)received $g#67. If you continue now in gdb it says:
:)"Can't send signals to this remote system.  SIGILL not sent." but it
:)continues and simulavr does also continue.

Yes, screwed this up. Fix (based on previous patch) attached.

:)
:)I send then a kill, and then simulavr crashes.
:)This is because gdb closes the pipe after the kill command and simulavr tries
:)to read from the pipe. It interpretes the kill command like the break command.
:)The solution is simple:
:)gdb_pre_parse_packet must return different return values for break and kill.
:)gdb_continue must simply terminate the loop and must send nothing to gdb if
:)it was a kill command.
:)In this case gdb_parse_packet must know that a kill command was received and
:)have to return -1. Remember at the beginning gdb_pre_parse_packet was called
:)from gdb_main_loop and now e are executing the return to this call.
:)

I don't think this is needed now that the C-c is handled correctly. Once
simulavr is in the continue loop, gdb is not at a prompt. To get a prompt
from gdb, user hits C-c, gdb passes it over the socket and simulavr breaks
out of the continue loop.  There's no way to send the kill while simulavr
is in the continue loop. I may be wrong, but I don't think simulavr will
receive anything from gdb except for a C-c while in the continue loop 
since gdb is waiting for some kinda of exception response from the remote 
target.

Here's a bit my gdb session showing this:

Breakpoint 1, main () at ../../simulavr/test_c/demo.c:18
18          outp( 0xff, DDRB );         /* enable port b for output */
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $s#73...Ack
Packet received: T0520:02;21:5e02;22:6000;
Sending packet: $Z0,5e,0#ac...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: 
Sending packet: $c#63...Ack
remote_interrupt called
remote_stop called
Packet received: T0520:02;21:5e02;22:7c00;

Program received signal SIGTRAP, Trace/breakpoint trap.
Sending packet: $g#67...Ack
Packet received: 
000000000000000000000000000000000000000000000000000060005e028000025e027c00
Sending packet: $m56,8#3c...Ack
Packet received: cee5d2e0debfcdbf
Sending packet: $z0,5e,0#cc...Ack
Packet received: OK
main () at ../../simulavr/test_c/demo.c:23
23          for (;;)
(gdb) 


Notice that after the $c..#.." packet is sent, gdb just sits there until I
hit C-c ("remote_interrupt called") at which point the '\003' is sent to
the sim, the sim breaks like a breakpoint and returns the "T05..." packet
to gdb.

The only potential problem I have with this is that the sim returns a
SIGTRAP instead of a SIGINT, but this works and allows you to keep working
without the sim aborting. Unless anyone has some compelling reasons to
change this behaviour, I'm going to leave it alone.

Ted

Here's the fix to correctly handle the C-c sent from gdb:

cat <<EOF
Index: gdbserver.c
===================================================================
RCS file: /home/cvsroot/simulavr/src/gdbserver.c,v
retrieving revision 1.9
diff -u -r1.9 gdbserver.c
--- gdbserver.c 2 Jan 2002 05:04:32 -0000       1.9
+++ gdbserver.c 2 Jan 2002 18:47:59 -0000
@@ -802,9 +802,8 @@
         case 0x03:
             /* Gdb send this when the user hits C-c. This is just gdb's
                way of telling us that an SIGINT has been requested by the
-               user. We shouldn't be replying with a SIGILL (S04). */
-            gdb_send_reply( fd, "S04" );
-            break;
+               user. Return -1 so caller knows to terminate any loops. */
+            return -1;
 
         case -1:
             /* fd is non-blocking and no data to read */
EOF