LLDB now shows additional string 'hardware' when a hardware breakpoint is hit. Current test fail for those kind of breakpoints, as they match exact string, which doesn't include 'hardware'.
The proposed solution is a regex match with an optional include of 'hardware' string (zero or one).
Details
- Reviewers
JDevlieghere jingham tatyana-krasnukha - Group Reviewers
Restricted Project - Commits
- rG9f0b5f9a39ea: [lldb/test] Added lldbutil function to test a breakpoint
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
All these tests are testing the same sort of thing. It would be better to make an lldbutil function that does this test and convert all these tests over to that. This sort of change is exactly why we don't want code that's poking at command results to find info about things like breakpoints scattered all over the testsuite.
Actually, they aren't testing the same "sort" of thing, it's exactly the same test: "was the breakpoint hit once". But those tests are also really inaccurate as they just ask whether any breakpoint has a hit count of 1. It would be really easy to edit a test, add another breakpoint that gets hit before you get to this self.expect. In that case, this test would stop testing what it was intended to test.
I know you didn't add these expects, but if you have the time it would be great to add lldbutils.GetBreakpointCount(breakpoint_no) and then actually pass the right breakpoint to the test...
What about the case when we have a logical BP with more than one location? the locations may have different hit count.
In particular we have a test like:
patterns=[
"1\.1: .+ unresolved, hit count = 0 +Options: disabled", "1\.2: .+ resolved,( hardware,)? hit count = 1", "1\.3: .+ resolved,( hardware,)? hit count = 1"])
If you have the breakpoint ID, you can find the SB Breakpoint and just ask it directly what it's hit count or location hit count are, and you don't have to scrub text output.
Jim
A diff updated with a new lldbutil function to test the breakpoint - check_breakpoint().
It looks like you missed one conversion. I agree with Pavel that None is not only more pythonic but also more lldbutils-y. Other than those nits, LGTM.
lldb/packages/Python/lldbsuite/test/lldbutil.py | ||
---|---|---|
738 | These could be two lists or a list of duples to allow matching against more than one location at a time, but we can do also that when we need it. | |
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py | ||
-1–1 | Why didn't you change this one to use your new function? |
lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py | ||
---|---|---|
-1–1 | check_breakpoint checks the correctness of a breakpoint and its locations, whereas this test seems to be checking that side_effect is correctly updated inside the breakpoint command script. |
There's one comment typo, but you can fix that on submission. Otherwise, LGTM.
lldb/packages/Python/lldbsuite/test/lldbutil.py | ||
---|---|---|
744 | location -> locations |
This change causes many test suite errors due to inline comment. Please fix ASAP
lldb/packages/Python/lldbsuite/test/lldbutil.py | ||
---|---|---|
759 | This line throws and exception when I run it on my system. It seems we have a function in lldbtest.py: # utility methods that tests can use to access the current objects def target(self): if not self.dbg: raise Exception('Invalid debugger instance') return self.dbg.GetSelectedTarget() And many tests actually set "self.target" to be a lldb.SBTarget with lines like: self.target = self.dbg.CreateTarget(exe) So this test fails for many objective C tests now with an exception |
The right fix IMHO is to rename the function in lldbtest.py from "def target(self):" to "def selected_target(self):" and then find all call sites and fix them.
Never mind, it seems to be fixed. Although the problem I mentioned is still true where some test cases might set "self.target = debugger.CreateTarget(...)" and if those test cases try to use the check_breakpoint function. See suggested code edit for a potential fix.
lldb/packages/Python/lldbsuite/test/lldbutil.py | ||
---|---|---|
759 | You can make this safer by doing the suggested code change |
None would be more pythonic