jasonmolenda added a comment. @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. :(
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. https://reviews.llvm.org/D27289 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
