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