athierry-oct wrote:
Sounds good, thank you!
In the test, it seems the intention was originally to set UnwindOnError to
true, but it's still set to false when evaluating the expression (there's no
call to `options.SetUnwindOnError(False)` after the comment that says "now set
UnwindOnError to true"):
TestCallThatRestarts.py
```python
options.SetUnwindOnError(False)
[...]
# Okay, now set UnwindOnError to true, and then make the signal behavior to stop
# and see that now we do stop at the signal point:
self.runCmd("process handle SIGCHLD -s 1 -p 1 -n 1")
value = frame.EvaluateExpression("call_me (%d)" % (num_sigchld), options)
self.assertTrue(value.IsValid())
self.assertFalse(value.GetError().Success())
# Set signal handling back to no-stop, and continue and we should end
# up back in out starting frame:
self.runCmd("process handle SIGCHLD -s 0 -p 1 -n 1")
error = process.Continue()
self.assertSuccess(error, "Continuing after stopping for signal succeeds.")
frame = self.thread.GetFrameAtIndex(0)
self.assertEqual(
frame.GetPC(),
self.orig_frame_pc,
"Continuing returned to the place we started.",
)
```
Do you prefer:
- keeping UnwindOnError set to false and having the test consume the stop event
- or setting UnwindOnError to true as the comment says, and adapt the rest of
the test (because after continuing, we won't stop at the same place as when
UnwindOnError is false, and the last assertion will fail) ?
https://github.com/llvm/llvm-project/pull/144919
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
