[Lldb-commits] [PATCH] D27289: Return "thread-pcs" in jstopinfo on Linux/Android.

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

@labath intersting idea, sending a blob of stack memory above the current stack pointer reg value to accelerate an unwind.  If you have a lot of small stack frames, it could be a performance benefit.  Common/simple methods do their work in 32-64 bytes of stack space (IMO) so we could look at the perf implications of sending up the 64 bytes of stack above $sp in the T packet.  We're locked into ascii for the T packet so we're talking about 128 characters plus 16 for the address.  It would only be needed on platforms where a frame pointer register is not used by default.  If you look at your packet logs, I bet lldb is doing a memory read on private stops as it tries to figure out what the caller function is - you could eliminate that packet with this, assuming smallish stack frames.

As mentioned, for wireless gdb-remote protocol (bluetooth, wifi) the performance characteristics are very different than for wired connections, but if we sent up that blob of stack data only on platforms without a fp reg used by default, it wouldn't impact the apple environments.

Agreed, I think we're all waiting for the addition of one more thing to the T packet to finally push us off of it, and to make up a new stop packet.  Greg's addition of jstopinfo almost did it for me personally. :)  The only thing I don't like about data sent in JSON is the base 10 requirement for numbers.  If we want to send up 64 bytes of stack memory, should we send that as an array of bytes?  Or an array of 64-bit ints that have been byteswapped by debugserver to big-endian format?  Right now debugserver sends up two words of memory at the frame pointer value - so 16 bytes on a 64-bit process - in native endian order, like

memory:0x7fff5fbffa90=a0fabf5fff7f0000ad95588fff7f0000;


https://reviews.llvm.org/D27289