This bug was originally reported here:
and has already been fixed by commit 26d56a939e9e54e09d46ea6e9678463ac344fa33.
Quoting from the original patch mail:
While trying to do some testing on one of our ARM boards via a debug probe and stub that speaks RSP, I was mystified by getting this error:
(gdb) target remote ...
(gdb) break main
Cannot detach breakpoints of inferior_ptid
Eventually I realized that this wasn't just a badly-worded message; GDB was somehow mis-interpreting the stop reply 'T05f:f0021000;' as TARGET_WAITKIND_FORKED, and wandering off into code that it shouldn't have been executing in the first place. (On ARM, register 0xf is the PC, BTW, and this particular stub works fine with a GDB from last year.)
Tracking it down further to remote_parse_stop_reply, the trouble is that the test
else if (strncmp (p, "fork", p1 - p) == 0)
is matching here; p1 points to the colon so it is matching exactly one character, the initial 'f'. While "fork" is new-ish, all the stop reason keywords use similar matching logic.
I don't see anything in the RSP documentation to indicate that the special stop reason keywords in a 'T' reply can be abbreviated, so I suspect this is just a think-o in the code, and it should be testing for an exact match of the keyword instead.
Bug has already been fixed on trunk.
And also in GDB 7.10 already. See:
Author: Sandra Loosemore <email@example.com>
Date: Tue Aug 18 10:37:31 2015 -0700
Fix mis-parsing of hex register numbers in 'T' stop replies
2015-08-18 Sandra Loosemore <firstname.lastname@example.org>
* remote.c (strprefix): New.
(remote_parse_stop_reply): Use strprefix instead of strncmp
to ensure exact match of keyword.