From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6EA663858D38; Thu, 26 Jan 2023 10:09:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6EA663858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674727792; bh=gEhv6MwqWd33E72N2LVr3eOaY02lgkUT+znByc3TC6w=; h=From:To:Subject:Date:From; b=RBy8pl4lWyCsgfE7jbim/VsD3ZPC5jmTbHvFjRhJwSV/bUtEzJ7MyEluKIbx5tNiK ihnQVV8HsOK0kbjWNnJFckAqqxzofwIRFGcoMtQqYU9l79PyogL/DKRvfm/4DdUNf7 h3B7b9M2ae6T6TenNaXoGQB+OIQP489tkn9UmXr0= From: "abidh at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug remote/30054] New: qC response is ignored with S packet. Date: Thu, 26 Jan 2023 10:09:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: remote X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: abidh at sourceware dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30054 Bug ID: 30054 Summary: qC response is ignored with S packet. Product: gdb Version: unknown Status: NEW Severity: normal Priority: P2 Component: remote Assignee: unassigned at sourceware dot org Reporter: abidh at sourceware dot org Target Milestone: --- We have noticed a change in behaviour since 24ed6739b699f329c2c45aedee5f8c7d2f54e493. Please see the log below. Targets send a S00 packet in the start. GDB gets the thread information using qC pa= cket and target supplies that information in the response. Later GDB ignores it = and picks the first thread anyway. I investigated it a bit and it seems that thread information that was obtai= ned in start_remote_1 gets overwritten by switch_to_inferior_no_thread. Later w= hen S00 packet is processed, it obviously does not have thread information and = GDB ends up calling select_thread_for_ambiguous_stop_reply. [remote] Sending packet: $qTStatus#49 [remote] Packet received:=20 [remote] packet_ok: Packet qTStatus (trace-status) is NOT supported [remote] Sending packet: $?#3f [remote] Packet received: S00 [remote] Sending packet: $qfThreadInfo#bb [remote] Packet received: mp2890.1 [remote] Sending packet: $qsThreadInfo#c8 [remote] Packet received: mp2890.2 [remote] Sending packet: $qsThreadInfo#c8 [remote] Packet received: mp2890.3 [remote] Sending packet: $qsThreadInfo#c8 [remote] Packet received: mp2890.4 [remote] Sending packet: $qsThreadInfo#c8 [remote] Packet received: l [remote] Sending packet: $qAttached:2890#9c [remote] Packet received:=20 [remote] packet_ok: Packet qAttached (query-attached) is NOT supported [remote] Sending packet: $Hc-1#09 [remote] Packet received: OK [remote] Sending packet: $qC#b4 [remote] Packet received: QCp2890.3 [remote] Sending packet: $qOffsets#4b [remote] Packet received:=20 [remote] wait: enter [remote] select_thread_for_ambiguous_stop_reply: enter [remote] select_thread_for_ambiguous_stop_reply: process_wide_stop = =3D 0 [remote] select_thread_for_ambiguous_stop_reply: first resumed thread= is Thread 10384.1 [remote] select_thread_for_ambiguous_stop_reply: is this guess ambigu= ous? =3D 1 warning: multi-threaded target stopped without sending a thread-id, using f= irst non-exited thread [remote] select_thread_for_ambiguous_stop_reply: exit [remote] wait: exit --=20 You are receiving this mail because: You are on the CC list for the bug.=