forked from OSchip/llvm-project
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 | ||
| README.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.