[lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

There is a standard for reverse stepping where the GDB remote protocol was extended to do the reverse stepping. See:

https://sourceware.org/gdb/onlinedocs/gdb/Packets.html <https://sourceware.org/gdb/onlinedocs/gdb/Packets.html>

Look for "reverse" in the text. They added "bc" for reverse continue and "bs" for reverse step. We should be using these if possible.



> On Aug 23, 2017, at 10:00 AM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
> 
> Perhaps a manual packet that tells your remote server that the next “s” packet is a reverse step, then run the lldb command “si”.
>  
> It would be simpler, from a packet log analysis standpoint, if you weren’t stopped at a breakpoint location when you did this.
>  
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>  
> From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Greg Clayton via lldb-dev
> Sent: Tuesday, August 22, 2017 6:20 PM
> To: Vadim Chugunov <vadimcn at gmail.com>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] Forcing lldb to refresh process state
>  
> You need to send some sort of continue through the GDB remote interface. The only way to get a $T packet back is in response to a "?" packet or to a "vCont" or other continue or step packet.
>  
>> On Aug 22, 2017, at 2:30 PM, Vadim Chugunov <vadimcn at gmail.com <mailto:vadimcn at gmail.com>> wrote:
>>  
>> It does send '$T05...' in response, but it looks like lldb does not analyze responses to manually sent packets.
>>  
>> On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton <clayborg at gmail.com <mailto:clayborg at gmail.com>> wrote:
>>> If you do a reverse step it actually should send a process resumed and a process stopped event.
>>> 
>>> > On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>> >
>>> > I'm trying to reverse-step.  So I think I'd need to refresh all thread states?
>>> >
>>> >> On Aug 18, 2017, at 4:50 PM, Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>> wrote:
>>> >>
>>> >> No, there hasn't been a need for this.
>>> >>
>>> >> What commands are you planning to send?  Or equivalently, how much state are you expecting to change?
>>> >>
>>> >> Jim
>>> >>
>>> >>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>> >>>
>>> >>> Hi,
>>> >>> Is there any way to force lldb to refresh it's internal record of debuggee process state (as if it had just received a stop event)?  I want to send a custom command to remote gdb process stub (via `process plugin packet send`).  This works, but if the command alters debuggee state, lldb won't know about it.
>>> >>> _______________________________________________
>>> >>> lldb-dev mailing list
>>> >>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>> >>
>>> > _______________________________________________
>>> > lldb-dev mailing list
>>> > lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170823/a6d66a54/attachment.html>