Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

> On Aug 23, 2017, at 1:37 PM, Vadim Chugunov  wrote:
> 
> 
> On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton  > wrote:
> This isn't a work around right? You should be triggering your reverse step or 
> reverse continue using a "process reverse-continue" or "thread reverse-step" 
> right? If you do this, everything will just work. There should be no way this 
> happens automagically without user interaction. Am I missing something?
> 
> Wait a second... As far as I know, LLDB itself does not support 
> reverse-debugging (unless I missed something in a major way).  So there is no 
> "process reverse-continue" command, is there?
> 
> I am not talking about adding proper reverse-debugging to lldb.  All I want 
> to do is to hack together a script that emulates "process reverse-continue" 
> in cases when remote target happens to support it.   I'm sending commands 
> directly to remote gdb via `process plugin packet send bs`, but that leaves 
> lldb out of the loop because it does not analyze the response packet.

Not sure why we wouldn't add it? It would be easy. The default implementation 
would return an unsupported error, and the ProcessGDBRemote would just pass the 
packets down.

Anything that internally calls lldb_private::Process::Flush() should do the 
trick as long as it actually causes it to get called. So:

target modules add
target modules load
target symbols add

They flush the process state because if you add a module or symbols or move a 
module around in memory we need to redo all stack traces. So you will need to 
do one of these as a work around and the command must succeed. I would suggest 
using:

(lldb) target modules add ...

where ... is the path of a shared library or executable that isn't in your 
target.


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton  wrote:

> This isn't a work around right? You should be triggering your reverse step
> or reverse continue using a "process reverse-continue" or "thread
> reverse-step" right? If you do this, everything will just work. There
> should be no way this happens automagically without user interaction. Am I
> missing something?
>

Wait a second... As far as I know, LLDB itself does not support
reverse-debugging (unless I missed something in a major way).  So there is
no "process reverse-continue" command, is there?

I am not talking about adding proper reverse-debugging to lldb.  All I want
to do is to hack together a script that emulates "process reverse-continue"
in cases when remote target happens to support it.   I'm sending commands
directly to remote gdb via `process plugin packet send bs`, but that leaves
lldb out of the loop because it does not analyze the response packet.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

This isn't a work around right? You should be triggering your reverse step or 
reverse continue using a "process reverse-continue" or "thread reverse-step" 
right? If you do this, everything will just work. There should be no way this 
happens automagically without user interaction. Am I missing something?


> On Aug 23, 2017, at 12:03 PM, Vadim Chugunov  wrote:
> 
> Yeah, this `bs` + `stepi` dance is the only workaround I found so far.
> 
> On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton  > wrote:
> 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 
> 
> 
> 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 > > 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”.
>>  

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

Yeah, this `bs` + `stepi` dance is the only workaround I found so far.

On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton  wrote:

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

Re: [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.woodw...@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-boun...@lists.llvm.org] On Behalf Of Greg 
> Clayton via lldb-dev
> Sent: Tuesday, August 22, 2017 6:20 PM
> To: Vadim Chugunov <vadi...@gmail.com>
> Cc: LLDB <lldb-dev@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 <vadi...@gmail.com 
>> <mailto:vadi...@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 <clayb...@gmail.com 
>> <mailto:clayb...@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@lists.llvm.org 
>>> > <mailto:lldb-dev@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 <jing...@apple.com 
>>> >> <mailto:jing...@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Ted Woodward via lldb-dev]

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-boun...@lists.llvm.org] On Behalf Of Greg
Clayton via lldb-dev
Sent: Tuesday, August 22, 2017 6:20 PM
To: Vadim Chugunov <vadi...@gmail.com>
Cc: LLDB <lldb-dev@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 <vadi...@gmail.com
<mailto:vadi...@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 <clayb...@gmail.com
<mailto:clayb...@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@lists.llvm.org
<mailto:lldb-dev@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 <jing...@apple.com
<mailto:jing...@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

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

Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim via lldb-dev]

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

Re: [lldb-dev] Forcing lldb to refresh process state

[Jim Ingham via lldb-dev]

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

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev