This is an archive of the discontinued LLVM Phabricator instance.

Handle a stop when another thread has hit a breakpoint with a failed condition
ClosedPublic

Authored by jingham on Jun 28 2022, 6:15 PM.

Details

Summary

Threads which hit a breakpoint but fail the condition are considered
not to be hit. But another thread might be hit at the same time and
actually stop. So we have to be sure to switch the first thread's
stop info to eStopReasonNone or we'll report a hit when the condition
failed, which is confusing.

I have a test for this, but it only tests the actual fix on systems that report
multiple threads hitting breakpoints on a given stop. Darwin
behaves this way, and w/o this fix the test fails on the first stop. But I give it
20 tries so this is likely to test the condition on systems that report multiple
hits less frequently. And for a system that serializes all stops, all this code is
moot anyway, and this is just testing breakpoint conditions.

Diff Detail

Event Timeline

jingham created this revision.Jun 28 2022, 6:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2022, 6:15 PM
jingham requested review of this revision.Jun 28 2022, 6:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2022, 6:15 PM
labath added a subscriber: labath.Jun 29 2022, 1:33 AM

(Other than the inline comment, this seems fine to me)

lldb/test/API/functionalities/breakpoint/two_hits_one_actual/main.cpp
7

usleep doesn't exist on windows. Use std::this_thread::sleep_for.

jingham updated this revision to Diff 441217.Jun 29 2022, 5:51 PM

Use sleep_for instead of usleep. Man, that API isn't winning any beauty contests!

Use sleep_for instead of usleep. Man, that API isn't winning any beauty contests!

well.. normally one would write that as sleep_for(std::chrono:microseconds(47)), or (if he's into that sort of thing) using namespace std::chrono_literals; sleep_for(47us);

This revision was not accepted when it landed; it landed in state Needs Review.Jun 30 2022, 11:44 AM
This revision was automatically updated to reflect the committed changes.