================
@@ -0,0 +1,281 @@
+"""
+Tests about which gdb-remote packets lldb sends while inspecting the stack at a
+public stop.
+
+On Darwin, debugserver expedites the frame-pointer backchain (up to 256 frames,
+for every thread) in the jThreadsInfo response at a public stop, and lldb seeds
+those bytes into its memory cache. Consequences exercised here:
+
+ * A backtrace (GetNumFrames() / GetFrameAtIndex() for every frame) is
+ satisfied entirely from the expedited/cached backchain and sends no
packets.
+ With the cache disabled it must read the backchain frame by frame, which
+ confirms the test is really exercising the unwinder's memory reads.
+
+ * Examining frame local variables the way an IDE does is NOT covered by the
+ expedite: the values live at addresses that were never sent up, so reading
+ them produces memory-read packets. This is checked two ways, mirroring
+ an IDE: examining only the selected frame's locals (frame 0, what a
+ variables view does on a stop) and examining every frame's locals (the
+ "view all frames" case).
+"""
+
+import os
+import re
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestExpeditedStackMemory(TestBase):
+ NO_DEBUG_INFO_TESTCASE = True
+
+ # A gdb-remote memory read is "$x<addr>,<len>" or "$m<addr>,<len>"; the
comma
+ # after the hex address distinguishes them from other packets.
----------------
qiyao wrote:
`after the hex address distinguishes them from other packets.` is confusing.
It is replaced with a cleaner and simpler one, `memory-read packet
("m<addr>,<len>" or "x<addr>,<len>")`.
https://github.com/llvm/llvm-project/pull/205897
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
