[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

[Jaroslav Sevcik via Phabricator via lldb-commits]

jarin added a comment.

Regarding the packet savings - there are still things that worry me.

First of all, when lldb CLI stops on a breakpoint, it will first unwind top of 
the stack of each thread as part of ThreadList::ShouldStop. This sends lots of 
"x" packets to lldb-server and only then issues jThreadInfo, which then replies 
with the stack memory uselessly (with my patch). I am yet to investigate why 
the CLI does that.

My patch saves messages when we start stepping after the breakpoint - in my 
example with a hundred threads, when we stop on a breakpoint, take a step and 
then do "thread list", there are no additional 'x' packets sent to lldb-server 
for the "thread list" command; without my patch there is a packet per-thread. 
In our VS extension, this seems to help quite a bit, but I am not so sure about 
the CLI.

It also feels like jThreadsInfo might not the best place to send the stacks - I 
am wondering whether jstopinfo in the vCont/c packet response would be a better 
place (even though the encoding of that is quite terrible). What do you think?




Comment at: 
lldb/packages/Python/lldbsuite/test/tools/lldb-server/threads-info/main.cpp:1
+#include 
+

labath wrote:
> I don't believe this include is needed.
Good catch, copypasta :-/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74398/new/

https://reviews.llvm.org/D74398



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

[Lldb-commits] [PATCH] D60962: [NativePDB] Extend .pdb files search folders

[Aaron Smith via Phabricator via lldb-commits]

asmith added a comment.
Herald added a subscriber: JDevlieghere.

Curious what the status of this is? Looks like its been ready for almost one 
year :)


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60962/new/

https://reviews.llvm.org/D60962



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

[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D74398#1935043 , @jarin wrote:

> Regarding the packet savings - there are still things that worry me.
>
> First of all, when lldb CLI stops on a breakpoint, it will first unwind top 
> of the stack of each thread as part of ThreadList::ShouldStop. This sends 
> lots of "x" packets to lldb-server and only then issues jThreadInfo, which 
> then replies with the stack memory uselessly (with my patch). I am yet to 
> investigate why the CLI does that.


I haven't looked into this, but this sound like the difference between a 
"private stop" and a "public stop".  When you do a source-level "next" command, 
lldb will put breakpoints on branches/function calls, run to those, then 
instruction step those instructions, etc.  Each time it stops at these 
breakpoints or instruction-steps.  Each of these stops are called private stops 
- the UI layer (lldb command line driver or the SB API driver) never hear about 
these.  When we've completed executing the instructions for that source line, 
then we declare this to be a "public stop" - this is when lldb driver or SB API 
driver, and the user, are notified that execution has stopped.

jThreadInfo is probably only retrieved when there is a public stop.  
debugserver puts two words of the current stack frame and the caller's stack 
frame in the questionmark (T05 etc) packet along with register contents for the 
frame that stopped.  The stepping thread plans need to know the current stack 
frame and the caller stack frame, to be sure that you didn't just step out of a 
function call or something.

For all the threads that aren't stepping, lldb should only need to know the 
current pc value - in the questionmark stop packet I also include the 
thread-pcs: list of pc values for each thread so we don't query them.

Look over the packet log while thinking about the difference between private 
stops and public stops and I think it might be easier to understand what's 
going on.

> My patch saves messages when we start stepping after the breakpoint - in my 
> example with a hundred threads, when we stop on a breakpoint, take a step and 
> then do "thread list", there are no additional 'x' packets sent to 
> lldb-server for the "thread list" command; without my patch there is a packet 
> per-thread. In our VS extension, this seems to help quite a bit, but I am not 
> so sure about the CLI.
> 
>   It also feels like jThreadsInfo might not the best place to send the stacks 
> - I am wondering whether jstopinfo in the vCont/c packet response would be a 
> better place (even though the encoding of that is quite terrible). What do 
> you think?




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74398/new/

https://reviews.llvm.org/D74398



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

[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D74398#1935431 , @jasonmolenda 
wrote:

> In D74398#1935043 , @jarin wrote:
>
> > Regarding the packet savings - there are still things that worry me.
> >
> > First of all, when lldb CLI stops on a breakpoint, it will first unwind top 
> > of the stack of each thread as part of ThreadList::ShouldStop. This sends 
> > lots of "x" packets to lldb-server and only then issues jThreadInfo, which 
> > then replies with the stack memory uselessly (with my patch). I am yet to 
> > investigate why the CLI does that.
>
>
> I haven't looked into this, but this sound like the difference between a 
> "private stop" and a "public stop".  When you do a source-level "next" 
> command, lldb will put breakpoints on branches/function calls, run to those, 
> then instruction step those instructions, etc.  Each time it stops at these 
> breakpoints or instruction-steps.  Each of these stops are called private 
> stops - the UI layer (lldb command line driver or the SB API driver) never 
> hear about these.  When we've completed executing the instructions for that 
> source line, then we declare this to be a "public stop" - this is when lldb 
> driver or SB API driver, and the user, are notified that execution has 
> stopped.


To give a quick example with some random binary I had sitting around,

  4 int main()
  5 {

-> 6std::vector a;

  7 a.push_back (0x0001);

(lldb) tar mod dump line-table a.cc
Line table for /tmp/a.cc in `a.out
0x00011220: /tmp/a.cc:5
0x0001122f: /tmp/a.cc:6:27
0x00011245: /tmp/a.cc:7:18
0x00011251: /tmp/a.cc:7:7

(lldb) dis -s 0x0001122f  -e 0x11245
a.out`main:
->  0x1122f <+15>: movq   %rax, %rdi

  0x11232 <+18>: movq   %rax, -0x68(%rbp)
  0x11236 <+22>: callq  0x11350   ; 
std::__1::vector 
>::vector at vector:497
  0x1123b <+27>: movabsq $0x1, %rax; imm = 0x1 

(lldb)

this source-level step will take 5 stops.  first go to the CALLQ, then 
instruction-step in, then set a breakpoint on the return address and continue, 
then stepi to the first instruction of line 7.  Let's look at what llvm does 
after it's instruction-stepped into the CALLQ,

<  18> send packet: $Z0,1123b,1#fc
 <   6> read packet: $OK#00
 <   5> send packet: $c#63
 < 624> read packet: 
$T05thread:5ada71;threads:5ada71;thread-pcs:1123b;00:58fabfeffe7f;01:;02:80fbbfeffe7f;03:90fabfeffe7f;04:58fabfeffe7f;05:58fabfeffe7f;06:60fabfeffe7f;07:e0f9bfeffe7f;08:;09:;0a:;0b:;0c:;0d:;0e:;0f:;10:3b120100;11:0202;12:2b00;13:;14:;metype:6;mecount:2;medata:2;medata:0;memory:0x7ffeefbffa60=70fabfeffe7ffdd7f765ff7f;memory:0x7ffeefbffa70=0100;#00
 <  18> send packet: $z0,1123b,1#1c
 <   6> read packet: $OK#00
 <  18> send packet: $vCont;s:5ada71#b5
 < 624> read packet: 
$T05thread:5ada71;threads:5ada71;thread-pcs:11245;00:0100;01:;02:80fbbfeffe7f;03:90fabfeffe7f;04:58fabfeffe7f;05:58fabfeffe7f;06:60fabfeffe7f;07:e0f9bfeffe7f;08:;09:;0a:;0b:;0c:;0d:;0e:;0f:;10:45120100;11:0202;12:2b00;13:;14:;metype:6;mecount:2;medata:1;medata:0;memory:0x7ffeefbffa60=70fabfeffe7ffdd7f765ff7f;memory:0x7ffeefbffa70=0100;#00
 <  16> send packet: $jThreadsInfo#c1
 < 889> read packet: 
$[{"tid":5954161,"metype":6,"medata":[1,0],"reason":"exception","qaddr":4295843648,"associated_with_dispatch_queue":true,"dispatch_queue_t":140735606695552,"qname":"com.apple.main-thread","qkind":"serial","qserialnum":1,"registers":{"0":"0100","1":"","[...]

So we set a breakpoint and continued to it to get out of the function call, 
then we cleared the breakpoint, stepi'ed to get to the first instruction of 
line 7 and now we've got a public stop and we issue a jThreadsInfo to get more 
expensive / exhaustive information about all threads, not just the thread that 
hit the breakpoint.

You can see debugserver providing enough of the stack memory in the memory: 
field in the questionmark (T05) packet so that lldb can walk the stack one 
frame and be sure of where it is.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74398/new/

https://reviews.llvm.org/D74398



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

[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

(and if you're still seeing mystery reads, put a breakpoint on 
ProcessGDBRemote::DoReadMemory and see who is doing it)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74398/new/

https://reviews.llvm.org/D74398



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

Re: [Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

[Jason Molenda via lldb-commits]

> On Mar 21, 2020, at 10:25 PM, Jason Molenda via Phabricator via lldb-commits 
>  wrote:
> 

> 
>  0x11232 <+18>: movq   %rax, -0x68(%rbp)
>  0x11236 <+22>: callq  0x11350   ; 
> std::__1::vector 
> >::vector at vector:497
>  0x1123b <+27>: movabsq $0x1, %rax; imm = 0x1 
> 
> 

> <   5> send packet: $c#63
> < 624> read packet: 
> $T05thread:5ada71;threads:5ada71;thread-pcs:1123b;00:58fabfeffe7f;01:;02:80fbbfeffe7f;03:90fabfeffe7f;04:58fabfeffe7f;05:58fabfeffe7f;06:60fabfeffe7f;07:e0f9bfeffe7f;08:;09:;0a:;0b:;0c:;0d:;0e:;0f:;10:3b120100;11:0202;12:2b00;13:;14:;metype:6;mecount:2;medata:2;medata:0;memory:0x7ffeefbffa60=70fabfeffe7ffdd7f765ff7f;memory:0x7ffeefbffa70=0100;#00
> <  18> send packet: $z0,1123b,1#1c
> <   6> read packet: $OK#00
> <  18> send packet: $vCont;s:5ada71#b5
> < 624> read packet: 
> $T05thread:5ada71;threads:5ada71;thread-pcs:11245;00:0100;01:;02:80fbbfeffe7f;03:90fabfeffe7f;04:58fabfeffe7f;05:58fabfeffe7f;06:60fabfeffe7f;07:e0f9bfeffe7f;08:;09:;0a:;0b:;0c:;0d:;0e:;0f:;10:45120100;11:0202;12:2b00;13:;14:;metype:6;mecount:2;medata:1;medata:0;memory:0x7ffeefbffa60=70fabfeffe7ffdd7f765ff7f;memory:0x7ffeefbffa70=0100;#00



(and anyone reading this packet sequence closely might ask, Hey, why doesn't 
lldb set the breakpoint on the next branch instruction/end-of-address-range 
after the return address, instead of the return address?  It would save a whole 
private stop!  This person would be correct and it would be interesting to look 
into finding a way to make the return thread plan do this! :)


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