This issue is extracted from https://sourceware.org/bugzilla/show_bug.cgi?id=31727. I get the 'Protocol error: QThreadEvents (thread-events) conflicting enabled' error when debugging the remote arm target in mingw. As suggested in https://sourceware.org/bugzilla/show_bug.cgi?id=31727 the first commit where the protocol error appears is 65c459abebf70bd5a64dcee11d4d7d4a8498465f. I get an internal error on the previous commit 26f047ce788b42b7b5f96515d119138a8ae43979. Logs for both commits attached.
Created attachment 15534 [details] no protocol error
Created attachment 15535 [details] protocol error
Definitely a bug, because the remote clearly does not respond with QThreadEvents+ This is a regression in 15 I think. I'm going to set the target milestone.
I don't understand why this branch would fail: void remote_target::thread_events (int enable) ... if (m_features.packet_support (PACKET_QThreadEvents) == PACKET_DISABLE) return; At least in a test build I did, if the remote doesn't include QThreadEvents+, then this packet seems to be disabled: (top-gdb) p m_features.packet_support(PACKET_QThreadEvents) $15 = PACKET_DISABLE Can you debug gdb with your remote and find out what's going on here? There's a loop at the end of remote_target::remote_query_supported that should make this change.
Created attachment 15564 [details] untruncated remote log For me m_features.packet_support(PACKET_QThreadEvents) == PACKET_ENABLE. I've collected untruncated remote log and it contains QThreadEvents+.
Ok, in this case, gdb is correct to give an error. What happens is that gdb sends "QThreadEvents+" in its qSupported packet. The remote replies "QThreadEvents+", meaning the packet is supported. Then later: &"[remote] Sending packet: $QThreadEvents:1#89\n" &"[remote] Packet received: \n" That is, gdb asks for thread events and the remote replies with the empty response, which means "unsupported" -- but it already said it *is* supported. This is a bug in the remote. Now, I do see the empty response documented in the manual. However, I tend to think this is a cut-and-paste bug in the manual itself, since the chart in the general query packets node says: Feature Name Value Default Probe Required Allowed ... ‘QThreadEvents’ No ‘-’ No i.e., probing isn't allowed, so the empty response -- IMO -- is nonsensical.
Although there's also the possibility that I am misunderstanding what "probe allowed" actually means, since the docs are kind of confusing on this topic.
Hey Tom, So, if I understand correct, the Protocol Error is caused by the remote, rather than a bug in GDB? Does it mean that this PR is no longer blocking for the GDB 15.1 release?
It might be caused by the remote, but the same remote works without an error with gdb-14 when the fix for https://sourceware.org/bugzilla/show_bug.cgi?id=31727 is applied.
I seem to either not have received an email notification when Dmitry replied to my message (despite me being subscribed) or (more likely) I must have missed the message. Sorry. Dmitry - I assume you're talking about https://sourceware.org/pipermail/gdb-patches/2024-June/209780.html ? I'm having trouble connecting the two, and so it seems to me as if the patch in question doesn't so much fix the problem as just takes GDB through a different path that no longer triggers the issue. Meanwhile, I think at this stage, with the information we have, I think we are better off releasing GDB 15.1 without a fix for this. The good news is that we can consider the idea of backporting the fix above to the gdb-15-branch and have that for the 15.2 release. I've asked the admins to create the 15.2 target milestone, and we should change this one to it once the milestone has been created.
FTR: I'm changing the target milestone per my previous comment.
> Dmitry - I assume you're talking about https://sourceware.org/pipermail/gdb-patches/2024-June/209780.html Yes. > ? I'm having trouble connecting the two, and so it seems to me as if the patch in question doesn't so much fix the problem as just takes GDB through a different path that no longer triggers the issue. Yes, the fix just takes GDB through a different path. Without the fix, assertion in https://sourceware.org/bugzilla/show_bug.cgi?id=31727 happens first and prevents assertion in this issue to happen.
I'm removing the milestone, and making this one as closed, since there is no fix to do (the problem is in the stub). Instead, what I have done is marked the workaround as a candidate for 15.2: https://sourceware.org/bugzilla/show_bug.cgi?id=31727