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

[Owen Shaw via lldb-dev]

I dug into this a bit more, and these output reply packets seem to be
handled already, but only if the program is running.

Since the relevant openocd commands are often issued when the program
paused, the reply packets aren't processed as expected.

The spec does say that reply packets can happen "any time while the
program is running", so perhaps openocd is abusing the protocol, but
gdb handles the packets just fine when stopped.

It's unclear in which other cases these packets would arrive when the
program is stopped, so I've put together a narrowed solution:

1. Adding GDBRemoteClientBase::SendPacketHandlingOutput(), with a
callback argument to handle any output
2. Calling SendPacketHandlingOutput() from
CommandObjectProcessGDBRemotePacketMonitor, providing a callback lamda
that uses an already-available output stream

It's a simpler and less intrusive solution, but will only apply to
"process plugin packet monitor" commands.  Perhaps that's sufficient.

Any thoughts still appreciated.

Thanks,
Owen

On Fri, Dec 29, 2017 at 11:37 AM, Owen Shaw <llvm at owenpshaw.net> wrote:
> 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