| Message ID | 1440723498-19075-1-git-send-email-lgustavo@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On 08/28/2015 01:58 AM, Luis Machado wrote: > GDB was not behaving correctly with qemu-system debugging: > > _ftext () at arm-vector.S:25 > 25 ldr pc, [pc, #24] @ reset > (gdb) load > Loading section .text, size 0xc01c lma 0x0 > Loading section .eh_frame, size 0x48 lma 0xc01c > Loading section .ARM.exidx, size 0x8 lma 0xc064 > Loading section .rodata, size 0x398 lma 0xc070 > Loading section .data, size 0x8e0 lma 0xc408 > Start address 0x40, load size 52452 > Transfer rate: 17074 KB/sec, 1748 bytes/write. > (gdb) c > Continuing. > infrun: clear_proceed_status_thread (Thread 1) > infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT) > infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 1] at 0x40 > Sending packet: $vCont?#49...Ack > Packet received: > Packet vCont (verbose-resume) is NOT supported > Sending packet: $Hc0#db...Ack > Packet received: OK > Sending packet: $c#63...Ack > infrun: infrun_async(1) > infrun: prepare_to_wait > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [Thread 0], > infrun: status->kind = ignore > infrun: TARGET_WAITKIND_IGNORE > infrun: prepare_to_wait > Packet received: Ffstat,00000001,07fffdb0 > Sending packet: $M7fffdb0,40:000000000000000000002080000000010000c336000001180000000000000000000000000000000000000200000000000000000055dfb11b55dfb11b55dfb11b#5a...Ack > Packet received: OK > Sending packet: $F0#76...Ack > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [Thread 0], > infrun: status->kind = ignore > infrun: TARGET_WAITKIND_IGNORE > infrun: prepare_to_wait > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [Thread 0], > infrun: status->kind = no-resumed > infrun: TARGET_WAITKIND_NO_RESUMED > infrun: stop_waiting > infrun: clear_step_over_info > Sending packet: $qfThreadInfo#bb...Ack > Packet received: m1 > Sending packet: $qsThreadInfo#c8...Ack > Packet received: l > No unwaited-for children left. > infrun: infrun_async(0) > (gdb) c > Continuing. > Cannot execute this command while the selected thread is running. > (gdb) > Continuing. > Cannot execute this command while the selected thread is running. > > This behavior shows up whenever GDB is in all-stop mode and is handling > target-initiated File-I/O requests, in the middle of, say, a continue > request. > > When GDB is done handling the File-I/O request, it doesn't set > rs->waiting_for_stop_reply back to 1, meaning GDB should wait for > further target events. > > This seems to be a latent bug, because in the past this didn't really > cause any issues. But it seems to have been uncovered by commit > 567420d10895611e03d5ee65e6b24c16a69a6e99, which explicitly checks > for rs->waiting_for_stop_reply == 0, triggering the failures above. > > The following patch fixes this by setting rs->waiting_for_stop_reply > back to 1 after handling the target-initiated File-I/O request. > > infrun: prepare_to_wait > Packet received: Ffstat,00000001,07fffdb0 > Sending packet: $M7fffdb0,40:000000000000000000002080000000010000c336000001180000000000000000000000000000000000000200000000000000000055dfb19e55dfb19e55dfb19e#7b...Ack > Packet received: OK > Sending packet: $F0#76...Ack > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [Thread 0], > infrun: status->kind = ignore > infrun: TARGET_WAITKIND_IGNORE > infrun: prepare_to_wait > Packet received: Fisatty,00000001 > Sending packet: $F1#77...Ack > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [Thread 0], > infrun: status->kind = ignore > infrun: TARGET_WAITKIND_IGNORE > infrun: prepare_to_wait > Packet received: Fwrite,00000001,0000d098,00000004 > Sending packet: $md098,4#d2...Ack > Packet received: 3732300a > 720 > Sending packet: $F4#7a...Ack > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [Thread 0], > infrun: status->kind = ignore > infrun: TARGET_WAITKIND_IGNORE > infrun: prepare_to_wait > Packet received: Fwrite,00000001,07ffffac,00000011 > Sending packet: $m7ffffac,11#8e...Ack > Packet received: 0a2a2a2a204558495420636f646520300a > > *** EXIT code 0 > > Regression-tested on Ubuntu x86-64 and qemu-system-based debugging > for arm eabi. > > OK? This is OK. Though I'd prefer if we removed the: /* We got something. */ rs->waiting_for_stop_reply = 0; line, and then cleared waiting_for_stop_reply in both the case 'E': case 'T': case 'S': case 'X': case 'W': cases. That'd make the check for waiting_for_stop_reply in interrupt_query work correctly while inside remote_console_output too: case 'O': /* Console output. */ remote_console_output (buf + 1); /* The target didn't really stop; keep waiting. */ rs->waiting_for_stop_reply = 1; Thanks, Pedro Alves
diff --git a/gdb/remote.c b/gdb/remote.c index 3afcaf4..31e67a9 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -6486,6 +6486,10 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) case 'F': /* File-I/O request. */ remote_fileio_request (buf, rs->ctrlc_pending_p); rs->ctrlc_pending_p = 0; + + /* GDB handled the File-I/O request, but the target is running + again. Keep waiting for events. */ + rs->waiting_for_stop_reply = 1; break; case 'T': case 'S': case 'X': case 'W': {