This is an archive of the discontinued LLVM Phabricator instance.

Speed up TestWatchpointMultipleThreads
ClosedPublic

Authored by labath on Feb 27 2018, 8:33 PM.

Details

Summary

The inferior was sleeping before doing any interesting work. I remove that
to make the test faster.

While looking at the purpose of the test (to check that watchpoints are
propagated to all existing threads - r140757) I noticed that the test has
diverged from the original intention and now it creates the threads *after* the
watchpoint is set (this probably happened during the std::thread refactor), so
I reorganize the test to be closer to the original intention.

The watchpoint propagation functionality is not really debug info depenent, so
I also stop replication of this test. This brings the test's time from ~108s
down to 4s.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Feb 27 2018, 8:33 PM
jingham added a comment.EditedFeb 28 2018, 10:05 AM

Getting watchpoints to propagate to threads that are created after the watchpoint has been set is one of the trickier parts of watchpoint propagation. On macOS, (where we don't get new thread creation notification) we rely on the kernel to propagate the control register settings to the thread contexts of newly created threads - a feature nobody but the debugger uses so we need to make sure it doesn't regress. On systems that don't have kernel cooperation you have to make sure that you catch new thread events and by hand set the control registers, again something we need to make sure we keep doing. If there's no other test that this works, then we should keep testing that in this test. It is the most fragile part of the interaction between watchpoints and threads.

OTOH making this a debug info independent test seems correct.

That's a good point. I think that at least TestConcurrentEvents do it that way, but they are testing a different thing. I think it makes sense to test both things here actually. I'll create one test which sets the watchpoint before thread creation and one after.

BTW, do you think there's any value in having three threads running around here? I think the test would be more obvious (and deterministic) if we had just one thread tripping the watchpoint.

Thanks!

While it seems possible somebody could write code that only sets the control registers on one thread and then gets tired and goes out for a beer, that seems like a really unlikely error. I don't think it's worth complicating the test to catch that possibility.

labath updated this revision to Diff 136361.Feb 28 2018, 12:36 PM

This makes the inferior more simple and deterministic by using a single thread.
Now we have one test which sets the watchpoint before the thread is created and
one that sets it after. I've also simplified the test a bit with new lldbutil
goodies.

Thanks for taking the time to do this!

Can you please double check some of the formatting in the python code? It looks like it's not indented properly.

labath updated this revision to Diff 136368.Feb 28 2018, 12:51 PM

Replace all tabs in the python file and clang-format the cpp file.

jingham accepted this revision.Feb 28 2018, 2:36 PM

Great, thanks!

This revision is now accepted and ready to land.Feb 28 2018, 2:36 PM
This revision was automatically updated to reflect the committed changes.