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

Reply via email to