From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id 6187E394D8A5 for ; Mon, 9 Mar 2020 17:35:53 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E3F4456035; Mon, 9 Mar 2020 13:35:52 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g88aQ-QJF5KA; Mon, 9 Mar 2020 13:35:52 -0400 (EDT) Received: from murgatroyd (184-96-250-69.hlrn.qwest.net [184.96.250.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id 8709B56033; Mon, 9 Mar 2020 13:35:52 -0400 (EDT) From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org, Pedro Alves Subject: Re: [PATCHv3 2/2] gdb/remote: Restore support for 'S' stop reply packet References: X-Attribution: Tom Date: Mon, 09 Mar 2020 11:35:52 -0600 In-Reply-To: (Andrew Burgess's message of "Mon, 2 Mar 2020 11:54:10 +0000") Message-ID: <87d09lwhvr.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 17:35:54 -0000 Andrew> There was a regression in GDB's support for older aspects of the Andrew> remote protocol. Specifically, when a target sends the 'S' stop reply Andrew> packet (which doesn't include a thread-id) then GDB has to figure out Andrew> which thread actually stopped. With this patch, I started seeing this warning when running the AdaCore internal test suite using qemu. I investigated a little and the warning comes from this packet: Packet received: W00 warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread It seems to me that the warning must not be correct in this case, though I am not 100% sure, so I thought I would ask. My reason is that this is a whole-process exit (so reporting a thread doesn't make sense); and that in this run, qemu is not reporting that it is multi-process-capable (so reporting a PID doesn't make sense). So, I wonder if process_stop_reply should be modified like (beware, untested patch): diff --git a/gdb/remote.c b/gdb/remote.c index 9b73faf9a34..810df658c54 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -7666,7 +7666,7 @@ remote_target::process_stop_reply (struct stop_reply *stop_reply, /* If no thread/process was reported by the stub then use the first non-exited thread in the current target. */ - if (ptid == null_ptid) + if (ptid == null_ptid && stop_reply->stop_reason != TARGET_WAITKIND_EXITED) { for (thread_info *thr : all_non_exited_threads (this)) { Perhaps this also applies to some of the other TARGET_WAITKIND_ values as well? TARGET_WAITKIND_SIGNALLED seems similar. thanks, Tom