[Lldb-commits] [PATCH] D27289: Return "thread-pcs" in jstopinfo on Linux/Android.

Fri Dec 2 11:11:05 PST 2016

> On Dec 2, 2016, at 2:47 AM, Pavel Labath via Phabricator via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> labath added a comment.
> 
> In https://reviews.llvm.org/D27289#611082, @jasonmolenda wrote:
> 
>> @labath ah I see I hadn't looked at the lldb-server packets so I didn't know you had jThreadsInfo, good to hear.  Yes, if your target is built mostly -fomit-frame-pointer, lldb-server won't be able to do a stack walk without reading eh_frame or the arm unwind info that Tamas added a year or so ago.  We've always avoided having lldb-server/debugserver know anything about files and symbols else the memory footprint will grow and we need these stubs to run in low-memory environments; I'm not sure how it could do a stalk walk.  It's a pretty big perf hit for lldb to walk to stacks of modern apps that have tens of threads on every public stop. :(
> 
> 
> I definitely don't want to add dwarf parsing code to lldb-server. We care a lot about the size of the binary as well.
> 
> Android studio does not crawl the stack of every thread after a stop -- it only displays the current one. What I was considering sending just K bytes of stack (for some reasonable value of K) around the SP of every thread, so that lldb does not need to do a memory read when computing the first frame of every thread (which I think we even if noone has asked that). But I'm talking in pretty vague terms now, as I haven't looked at this seriously yet. Last time I did a protocol profile, memory reads did not come up as a big problem, so I have not investigated this in details.

I don't think trying to accelerate a complete stack walk in the stop packet is desirable.  You would only use that information on a public stop, which are ~10-20% of the total number of stops.  So you would be computing and sending over a bunch of information that wasn't needed most of the time.  And I agree that putting the code required to do an accurate stack walk into lldb-server is not a good idea.

However, every time you stop (not just public stops) threads that have non-trivial thread plans will generally need to find the current frame and its caller.  I try really hard not to ask for more information than I need to do the job, but that's generally the minimum I can get away with.  And we don't ask for this information for any threads that the user isn't stepping on, so we really only ask for the caller frame for one or two threads per stop.  

Note,  that much of the packet optimization Jason did was successful in cutting down the packet count, but was not all that significant when debugging to an iOS device where you have a decently fast connection to debugserver.  OTOH, even this level of optimization was significant for watchOS, which talks over bluetooth and the per packet cost is quite high for that communication channel.  I don't know what environments you are supporting, but it's something to keep in mind.

Jim

> 
>> Agree with not sending the registers in the jstopinfo kv pair in the T/? packet - \it's such a space-inefficient encoding compared to the usual kv pairs of info in the T packet, as weirdly as they're formatted.  JSON requires we use base 10 for numbers, and then ascii-hex encoding it doubles it (I played with the idea of using base64 for jstopinfo originally, but instead worked on including the smallest amount of info we needed).
>> 
>> If we were going to be serious about the T packet format, I think we'd add a new JT packet (or whatever) which is all the information in straight JSON, and some request from lldb to enable JT packets instead of T packets.  But it doesn't seem like a pressing concern, and the more we deviate from standard gdb-remote protocol (even if it's optional deviation with fallback to standard packets), I think it makes lldb more fragile for interop.
> 
> I'd support switching to a new stop-reply format, the current one has a lot of ad-hoc hacks glued onto it.
> 
> 
> https://reviews.llvm.org/D27289
> 
> 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits