[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
Add func call so we don't instruction-step into the builtin_trapThe way this test is structured right now, I set a breakpoint onthe instruction before the __builtin_trap. It hits the breakpoint,
Add func call so we don't instruction-step into the builtin_trapThe way this test is structured right now, I set a breakpoint onthe instruction before the __builtin_trap. It hits the breakpoint,disables the breakpoint, and instruction steps. This hits thebuiltin_trap instruction which debugserver (on arm64) now advancesto the next instruction and reports that address to lldb. lldbdoesn't recognize this as a proper response to the instructionstep and continues executing until the next trap, and the test fails.
debugserver should advance pc past builtin_debugtrap insnOn x86_64, when you hit a __builtin_debugtrap instruction, youcan continue past this in the debugger. This patch has debugserverrecognize
debugserver should advance pc past builtin_debugtrap insnOn x86_64, when you hit a __builtin_debugtrap instruction, youcan continue past this in the debugger. This patch has debugserverrecognize the specific instruction used for __builtin_debugtrapand advance the pc past it, so that the user can continue executiononce they've hit one of these.In the patch discussion, we were in agreement that it would be betterto have this knowledge up in lldb instead of depending on eachstub rewriting the pc behind the debugger's back, but that's alarger scale change for another day.<rdar://problem/65521634>Differential revision: https://reviews.llvm.org/D91238