This bug was originally reported here: https://sourceware.org/ml/gdb-patches/2015-08/msg00413.html 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 (gdb) load (gdb) c 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: commit e13cbb569965ee3baca2ad4801eeb910c2b2f03f Author: Sandra Loosemore <sandra@codesourcery.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 <sandra@codesourcery.com> gdb/ * remote.c (strprefix): New. (remote_parse_stop_reply): Use strprefix instead of strncmp to ensure exact match of keyword.