[lldb-dev] How to handle "O XX..." reply packets from gdb servers like openocd

[Owen Shaw via lldb-dev]

Looking for guidance.  This seems like an lldb issue, but maybe I'm
missing something.  And while I have a potential solution, I'm not
familiar enough with lldb code to know if its a "good" solution.

Background
----------

openocd sends mutliple "O XX..." reply packets
(https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html) in
response to certain commands.  The XX... hex payload should be decoded
and printed for the lldb user.

For example,

(lldb) process plugin packet monitor help

Results in a gdb client/server packet sequence like:

-> $qRcmd,68656c70#fc
<- $O#4f
<- $O616461707465725f6b687a#66
<- $O5b6b687a5d0a#ae
... (many more $O packets)
<- $OK#9a

and should print in the lldb console something like:

adapter [khz]
... (many more lines)


The Issues
----------

1) lldb assumes the first O packet is the command response, so it
thinks the command failed since O is an unknown response
2) lldb only reads the first O packet, causing subsequent commands to
read the remaining O reply packets from the first command as their
responses
3) lldb doesn't print the O packet payloads as expected


Possible Solution
-----------------

I've coded up a possible solution:

1) Add StringExtractorGDBRemote::IsOutputResponse() that returns true
for O packets
2) Have GDBRemoteCommunication::ReadPacket() check IsOutputResponse()
as it reads
3) If ReadPacket() sees an O packet, print its payload and read
another packet.  Keep looping and return the first non-O packet.
4) Add an output stream member to GDBRemoteCommunication so it can
print to the lldb console

Seems to work.  I see the expected command output in the lldb console,
the command succeeds, and subsequent commands read the correct
responses.

If this is anywhere near the right track, I can look into writing test
cases and submitting a patch for closer evaluation.

Thanks,
Owen