Michael137 added a comment.
After playing around with this some more I found an edge case with conditional
breakpoints (in fact any place where we reuse an LLVMUserExpression). Modifying
`lldb/test/API/functionalities/breakpoint/two_hits_one_actual` such that the
helper method is inside a lambda like so:
struct Foo {
void usleep_helper(int usec) {
[this, &usec] {
// Break here in the helper
std::this_thread::sleep_for(std::chrono::duration<unsigned int,
std::milli>(usec));
}();
}
};
void *background_thread(void *arg) {
(void) arg;
Foo f;
for (;;) {
f.usleep_helper(2);
}
}
int main(void) {
std::thread main_thread(background_thread, nullptr);
Foo f;
for (;;) {
f.usleep_helper(1);
}
}
Then setting a breakpoint twice, one for `usec == 1` and `usec == 100`, we
would end up hitting the breakpoint even if `usec == 2` because conditional
breakpoints re-use Materializer (and thus Entity objects). Since
`EntityValueObject::GetValueObject` simply returns the ValueObject it was
instantiated with, the `usec == 1` condition always evaluates to `true`. Have a
fix for this but verifying whether that really is the best approach.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D129078/new/
https://reviews.llvm.org/D129078
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
