This ensures it is run regardless of the method we use to initiate the
session (previous version did not handle connects), and it is the same
place that is used for resetting watchpoints.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
If there's some guarantee that Target::CreateProcess HAS to be the way that a process is created, then this is fine. Is there such a guarantee - the function is pretty trivial so somebody might be tempted to do the work in some other place but miss the breakpoint resetting.
I'm not sure what kind of guarantees are you looking for. m_process_sp is a private member of the Target class, so it's not like just anyone can come in and change it. There's no way to stop code from inside the Target class from changing it without going through the CreateProcess method, but the same can be said about the calls to WillXXX methods in the process class.
The WillXXX have the virtue that they are at least self-documenting "Before you do XXX this will be called." As it stands somebody working on Target could be forgiven for thinking Target::CreateProcess was just a convenience method, and redo it somewhere inline forgetting the breakpoint resetting. If we are going to require CreateProcess as the only way to do this, we should at least state that somewhere.
Here's an even better idea. I've now doing it in Target::CleanupProcess, right next to the code for resetting watchpoint hit counts.
That seems fine. I think it's useful to be able to see breakpoint hit counts up to the point where you start a new process. From looking at the code, it looks like putting the clear in CleanupProcess will do that. If you agree this is useful, can you add to the test that the hit count is still 1 between process.Kill and connecting to the new process? Other than that this seems fine.