Then the right way to fix this is to somehow allow the rCmd to watch for the "O" packets in its responses. Since no other commands want this and the send continue packets use a special send packet and receive response, we might must want a SendPacketAndReceiveResponseWithOutputSupport(...) that rCmd will use. We could also add a bool to the stand send packet and receive response that indicates if "O" packet responses are possible, my only objection to that is it makes it seem like any command can just opt into getting "O" responses. If rCmd is the only other packet other than continue, I would do add the SendPacketAndReceiveResponseWithOutputSupport and call it explicitly from the rCmd handler. I am open to other suggestions.
Greg > On Jan 4, 2018, at 9:14 AM, Pedro Alves <pal...@redhat.com> wrote: > > On 01/03/2018 07:11 PM, Greg Clayton via lldb-dev wrote: >> >>> On Jan 1, 2018, at 6:30 PM, Owen Shaw via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> >>> 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. >> >> Yes, LLDB is assuming that an "O" packet will only come during a continue >> command. "O" is for stdout output and it seems the rCmd assuming it will >> work. Why not just send back the text in response to the rCmd? Is some >> common code path being hit where it might send this text while running and >> also in response to the rCmd? I am confused by "O" packets are needed in >> response to the rCmd. > > qRcmd was invented well before my time, but qRcmd provides support > for running random interpreter commands on the server, with the > resulting output being potentially long, unbounded. Thus sending the > text back in response to qRcmd would require an unbounded packet buffer > and would potentially hit the max packet size. So you'd need some > way to send partial output in chunks. Which ends up being exactly what > you get by reusing "O". > >> If the rCmd can't be fixed to just return the text without using "O" >> packets, > > The documentation of the qRcmd packet explicitly specifies that output > should be sent via "O" packets: > > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#index-qRcmd-packet > > <https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#index-qRcmd-packet> > > Sounds like OpenOCD is working as intended. > > Pedro Alves
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
