* [PATCH] Make GDB wait for events after handling target File-I/O @ 2015-08-28 0:58 Luis Machado 2015-09-10 12:59 ` Pedro Alves 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado @ 2015-08-28 0:58 UTC (permalink / raw) To: gdb-patches 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? gdb/ChangeLog: 2015-08-27 Luis Machado <lgustavo@codesourcery.com> * remote.c (remote_wait_as): Reset rs->waiting_for_stop_reply to 1 after handling File-I/O. --- gdb/remote.c | 4 ++++ 1 file changed, 4 insertions(+) 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': { -- 1.9.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Make GDB wait for events after handling target File-I/O 2015-08-28 0:58 [PATCH] Make GDB wait for events after handling target File-I/O Luis Machado @ 2015-09-10 12:59 ` Pedro Alves 2015-10-16 19:30 ` Luis Machado 0 siblings, 1 reply; 7+ messages in thread From: Pedro Alves @ 2015-09-10 12:59 UTC (permalink / raw) To: Luis Machado, gdb-patches 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Make GDB wait for events after handling target File-I/O 2015-09-10 12:59 ` Pedro Alves @ 2015-10-16 19:30 ` Luis Machado 2015-10-19 9:22 ` Pedro Alves 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado @ 2015-10-16 19:30 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 5198 bytes --] On 09/10/2015 09:59 AM, Pedro Alves wrote: > 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 > [now cc-ing the list] How does the attached update look? I did not move this statement: rs->stop_reason = TARGET_STOPPED_BY_NO_REASON; ... since it only makes sense with the right value of rs->waiting_for_stop_reply, but it could also be set within each case statement. [-- Attachment #2: fileio.diff --] [-- Type: text/x-patch, Size: 1845 bytes --] 2015-10-16 Luis Machado <lgustavo@codesourcery.com> * remote.c (remote_wait_as): Reset rs->waiting_for_stop_reply when handling 'E', 'T', 'S', 'X' and 'W' packets. Set rs->waiting_for_stop_reply to 1 after handling 'F' packets. diff --git a/gdb/remote.c b/gdb/remote.c index f40f791..87b0b58 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -6635,9 +6635,6 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) rs->stop_reason = TARGET_STOPPED_BY_NO_REASON; - /* We got something. */ - rs->waiting_for_stop_reply = 0; - /* Assume that the target has acknowledged Ctrl-C unless we receive an 'F' or 'O' packet. */ if (buf[0] != 'F' && buf[0] != 'O') @@ -6648,6 +6645,8 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) case 'E': /* Error of some sort. */ /* We're out of sync with the target now. Did it continue or not? Not is more likely, so report a stop. */ + rs->waiting_for_stop_reply = 0; + warning (_("Remote failure reply: %s"), buf); status->kind = TARGET_WAITKIND_STOPPED; status->value.sig = GDB_SIGNAL_0; @@ -6655,10 +6654,19 @@ 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': { - struct stop_reply *stop_reply + struct stop_reply *stop_reply; + + /* There is a stop reply to handle. */ + rs->waiting_for_stop_reply = 0; + + stop_reply = (struct stop_reply *) remote_notif_parse (¬if_client_stop, rs->buf); ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Make GDB wait for events after handling target File-I/O 2015-10-16 19:30 ` Luis Machado @ 2015-10-19 9:22 ` Pedro Alves 2015-10-19 13:22 ` Luis Machado 0 siblings, 1 reply; 7+ messages in thread From: Pedro Alves @ 2015-10-19 9:22 UTC (permalink / raw) To: Luis Machado, gdb-patches On 10/16/2015 08:30 PM, Luis Machado wrote: > How does the attached update look? Is there a reason to keep the "rs->waiting_for_stop_reply = 1;" lines? Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Make GDB wait for events after handling target File-I/O 2015-10-19 9:22 ` Pedro Alves @ 2015-10-19 13:22 ` Luis Machado 2015-10-19 13:24 ` Pedro Alves 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado @ 2015-10-19 13:22 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 371 bytes --] On 10/19/2015 07:21 AM, Pedro Alves wrote: > On 10/16/2015 08:30 PM, Luis Machado wrote: > >> How does the attached update look? > > Is there a reason to keep the "rs->waiting_for_stop_reply = 1;" lines? No, that was a mistake since we inverted the logic. What about the following? Now we'll only set rs->waiting_for_stop_reply to 1 when resuming in "all-stop" mode. [-- Attachment #2: fileio.diff --] [-- Type: text/x-patch, Size: 2536 bytes --] 2015-10-19 Luis Machado <lgustavo@codesourcery.com> * remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to 0 when handling 'E', 'T', 'S', 'X' and 'W' packets. Do not set rs->waiting_for_stop_reply back to 1. --- gdb/remote.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/gdb/remote.c b/gdb/remote.c index f40f791..fed397a 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -6635,9 +6635,6 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) rs->stop_reason = TARGET_STOPPED_BY_NO_REASON; - /* We got something. */ - rs->waiting_for_stop_reply = 0; - /* Assume that the target has acknowledged Ctrl-C unless we receive an 'F' or 'O' packet. */ if (buf[0] != 'F' && buf[0] != 'O') @@ -6648,6 +6645,8 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) case 'E': /* Error of some sort. */ /* We're out of sync with the target now. Did it continue or not? Not is more likely, so report a stop. */ + rs->waiting_for_stop_reply = 0; + warning (_("Remote failure reply: %s"), buf); status->kind = TARGET_WAITKIND_STOPPED; status->value.sig = GDB_SIGNAL_0; @@ -6658,7 +6657,12 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) break; case 'T': case 'S': case 'X': case 'W': { - struct stop_reply *stop_reply + struct stop_reply *stop_reply; + + /* There is a stop reply to handle. */ + rs->waiting_for_stop_reply = 0; + + stop_reply = (struct stop_reply *) remote_notif_parse (¬if_client_stop, rs->buf); @@ -6667,10 +6671,6 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) } case 'O': /* Console output. */ remote_console_output (buf + 1); - - /* The target didn't really stop; keep waiting. */ - rs->waiting_for_stop_reply = 1; - break; case '\0': if (rs->last_sent_signal != GDB_SIGNAL_0) @@ -6686,17 +6686,11 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) strcpy ((char *) buf, rs->last_sent_step ? "s" : "c"); putpkt ((char *) buf); - - /* We just told the target to resume, so a stop reply is in - order. */ - rs->waiting_for_stop_reply = 1; break; } /* else fallthrough */ default: warning (_("Invalid remote reply: %s"), buf); - /* Keep waiting. */ - rs->waiting_for_stop_reply = 1; break; } -- 1.9.1 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Make GDB wait for events after handling target File-I/O 2015-10-19 13:22 ` Luis Machado @ 2015-10-19 13:24 ` Pedro Alves 2015-10-19 13:37 ` Luis Machado 0 siblings, 1 reply; 7+ messages in thread From: Pedro Alves @ 2015-10-19 13:24 UTC (permalink / raw) To: Luis Machado, gdb-patches On 10/19/2015 02:21 PM, Luis Machado wrote: > On 10/19/2015 07:21 AM, Pedro Alves wrote: >> On 10/16/2015 08:30 PM, Luis Machado wrote: >> >>> How does the attached update look? >> >> Is there a reason to keep the "rs->waiting_for_stop_reply = 1;" lines? > > No, that was a mistake since we inverted the logic. What about the > following? > > Now we'll only set rs->waiting_for_stop_reply to 1 when resuming in > "all-stop" mode. > Thanks. This version LGTM. -- Pedro Alves ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Make GDB wait for events after handling target File-I/O 2015-10-19 13:24 ` Pedro Alves @ 2015-10-19 13:37 ` Luis Machado 0 siblings, 0 replies; 7+ messages in thread From: Luis Machado @ 2015-10-19 13:37 UTC (permalink / raw) To: Pedro Alves, gdb-patches On 10/19/2015 11:24 AM, Pedro Alves wrote: > On 10/19/2015 02:21 PM, Luis Machado wrote: >> On 10/19/2015 07:21 AM, Pedro Alves wrote: >>> On 10/16/2015 08:30 PM, Luis Machado wrote: >>> >>>> How does the attached update look? >>> >>> Is there a reason to keep the "rs->waiting_for_stop_reply = 1;" lines? >> >> No, that was a mistake since we inverted the logic. What about the >> following? >> >> Now we'll only set rs->waiting_for_stop_reply to 1 when resuming in >> "all-stop" mode. >> > > Thanks. This version LGTM. > Thanks. Pushed now as 29090fb629734b7980f058f4a7e24a0369e9bb49. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-19 13:37 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-28 0:58 [PATCH] Make GDB wait for events after handling target File-I/O Luis Machado 2015-09-10 12:59 ` Pedro Alves 2015-10-16 19:30 ` Luis Machado 2015-10-19 9:22 ` Pedro Alves 2015-10-19 13:22 ` Luis Machado 2015-10-19 13:24 ` Pedro Alves 2015-10-19 13:37 ` Luis Machado
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox