[Bug gdb/19245] New: fix misparsing in remote_parse_stop_reply

["sandra at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19245

            Bug ID: 19245
           Summary: fix misparsing in remote_parse_stop_reply
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: sandra at codesourcery dot com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.