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
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
>> 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
Hi Greg,
I've been assuming that we can't force a change to openocd's behavior,
or at least that the easier path is to handle its current behavior. I
don't know why openocd sends O packets in response to an rCmd, but it
does and gdb is okay with it.
I'm still learning my way around the lldb code
> On Jan 1, 2018, at 6:30 PM, Owen Shaw via lldb-dev
> 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 are
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
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/
