Re: [PATCH] Make GDB wait for events after handling target File-I/O

[Pedro Alves <palves at redhat dot com>]

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