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.
lldb-commits mailing list