mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-12-22 07:22:54 +00:00
faf5f1cbba
Using a DexLimitSteps command forces dexter to use the ConditionalController debugger controller. At each breakpoint the ConditionalController needs to understand which one has been hit. Prior to this patch, upon hitting a breakpoint, dexter used the current source location to look up which requested breakpoint had been hit. A breakpoint may not get set at the exact location that the user (dexter) requests. For example, if the requested breakpoint location doesn't exist in the line table then then debuggers will (usually, AFAICT) set the breakpoint at the next available valid breakpoint location. This meant that, occasionally in unoptimised programs and frequently in optimised programs, the ConditionalController was failing to determine which breakpoint had been hit. This is the fix: Change the DebuggerBase breakpoint interface to use opaque breakpoint ids instead of using source location to identify breakpoints, and update the ConditionalController to track breakpoints instead of locations. These now return a breakpoint id: add_breakpoint(self, file_, line) _add_breakpoint(self, file_, line) add_conditional_breakpoint(self, file_, line, condition) _add_conditional_breakpoint(self, file_, line, condition) Replace: delete_conditional_breakpoint(self, file_, line, condition) _delete_conditional_breakpoint(self, file_, line, condition) with: delete_breakpoint(self, id) Add: get_triggered_breakpoint_ids(self) A breakpoint id is guaranteed to be unique for each requested breakpoint, even for duplicate breakpoint requests. Identifying breakpoints like this, instead of by location, removes the possibility of mixing up requested and bound breakpoints. This closely matches the LLDB debugger interface so little work was required in LLDB.py, but some extra bookkeeping is required in VisualStudio.py to maintain the new breakpoint id semantics. No implementation work has been done in dbgeng.py as DexLimitSteps doesn't seem to support dbgeng at the moment. Testing Added: dexter/feature_tests/commands/perfect/limit_steps/limit_steps_line_mismatch.cpp There were no unexpected failures running the full debuginfo-tests suite. The regression tests use dbgeng on windows by default, and as mentioned above dbgeng isn't supported yet, so I have also manually tested (i.e. without lit) that this specific test works as expected with clang and Visual Studio 2017 on Windows. Reviewed By: TWeaver Differential Revision: https://reviews.llvm.org/D98699 |
||
---|---|---|
.. | ||
dexter | ||
dexter-tests | ||
llgdb-tests | ||
llvm-prettyprinters/gdb | ||
win_cdb-tests | ||
CMakeLists.txt | ||
lit.cfg.py | ||
lit.site.cfg.py.in | ||
README.txt |
-*- rst -*- This is a collection of tests to check debugging information generated by compiler. This test suite can be checked out inside clang/test folder. This will enable 'make test' for clang to pick up these tests. Some tests (in the 'llgdb-tests' directory) are written with debugger commands and checks for the intended debugger output in the source file, using DEBUGGER: and CHECK: as prefixes respectively. For example:: define i32 @f1(i32 %i) nounwind ssp { ; DEBUGGER: break f1 ; DEBUGGER: r ; DEBUGGER: p i ; CHECK: $1 = 42 entry: } is a testcase where the debugger is asked to break at function 'f1' and print value of argument 'i'. The expected value of 'i' is 42 in this case. Other tests are written for use with the 'Dexter' tool (in the 'dexter-tests' and 'dexter' directories respectively). These use a domain specific language in comments to describe the intended debugger experience in a more abstract way than debugger commands. This allows for testing integration across multiple debuggers from one input language. For example:: void __attribute__((noinline, optnone)) bar(int *test) {} int main() { int test; test = 23; bar(&test); // DexLabel('before_bar') return test; // DexLabel('after_bar') } // DexExpectWatchValue('test', '23', on_line='before_bar') // DexExpectWatchValue('test', '23', on_line='after_bar') Labels two lines with the names 'before_bar' and 'after_bar', and records that the 'test' variable is expected to have the value 23 on both of them.