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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
