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

Fri Dec 2 02:47:14 PST 2016

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.

> 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