> On Dec 2, 2016, at 2:47 AM, Pavel Labath via Phabricator via lldb-commits > <lldb-commits@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
