This is an archive of the discontinued LLVM Phabricator instance.

Fixes http://reviews.llvm.org/rL230691
ClosedPublic

Authored by chaoren on Feb 26 2015, 11:14 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

chaoren updated this revision to Diff 20830.Feb 26 2015, 11:14 PM
chaoren retitled this revision from to Fixes http://reviews.llvm.org/rL230691.
chaoren updated this object.
chaoren edited the test plan for this revision. (Show Details)
chaoren added a reviewer: ki.stfu.
chaoren added a subscriber: Unknown Object (MLST).
ki.stfu requested changes to this revision.Feb 26 2015, 11:36 PM
ki.stfu edited edge metadata.
ki.stfu added inline comments.
test/functionalities/watchpoint/hello_watchlocation/main.cpp
107 ↗(On Diff #20830)

it was useful.

This revision now requires changes to proceed.Feb 26 2015, 11:36 PM
chaoren updated this revision to Diff 20831.Feb 26 2015, 11:42 PM
chaoren edited edge metadata.

Accidentally removed the memory leak fix.

ki.stfu accepted this revision.Feb 26 2015, 11:46 PM
ki.stfu edited edge metadata.

Looks good. I haven't tested it yet, but you can commit it if you have.

I'll check it a bit later.

This revision is now accepted and ready to land.Feb 26 2015, 11:46 PM
This revision was automatically updated to reflect the committed changes.

I'll check it a bit later.

Yep. It works on OS X.

clayborg edited edge metadata.Feb 27 2015, 9:37 AM

Someone else already posted a fix for this that used pthread_condition_t and pthread_mutex_t, so don't commit this.

zturner added inline comments.Feb 27 2015, 9:40 AM
lldb/trunk/test/functionalities/watchpoint/hello_watchlocation/main.cpp
58

std::condition_variable?

65

I understand this isn't your code, but RAND_MAX is not guaranteed to be > 32768. On Windows, it isn't. std::random would be better here.

93–95

Since we're already bringing in std::atomic, how about std::thread while we're at it? That would make this testcase compile on Windows.

@Greg, the author of the other fix and I have sort of decided among
ourselves to abandon his fix and use this instead.

@zach, would it be better if I just rewrote this entire test with C++11
instead of C? Should that be a general rule for all tests in the future?

I like your fix better. The C++ way will spin one CPU while waiting for a global to change. I much prefer this solution the other thread will park itself instead of spin locking.

I meant to say I like the other fix that uses pthread_condion_t and pthread_mutex_t since it won't spin like this fix will. Please use the other one.

I'm rewriting the test to use std::condition_variable and other C++11
alternatives.

zturner edited edge metadata.Feb 27 2015, 10:16 AM

I meant to say I like the other fix that uses pthread_condion_t and pthread_mutex_t since it won't spin like this fix will. Please use the other one.

Just to be clear, are you saying you don't want C++11 at all? Or that you just want a condition variable instead of a spinlock? Because if you just want a condition variable, then we should go with the C++11 and std::condition_variable as I suggested, since the test will work on platforms that don't have pthreads.

@zach, would it be better if I just rewrote this entire test with C++11
instead of C? Should that be a general rule for all tests in the future?

It's not a general rule for *all* tests, but I think it should be a general rule for all tests that aren't specifically testing a property of the debugger that requires only C code. So I think it should be a general rule for *almost* all tests, but there may occasionally be valid reasons to test strict C.

As I commented in the other fix for this bug, we should move to using the correct C++11 primitives to abstract us from the host system. pthread_ types and functions obviously don't do this.

I strongly feel we should use std::condition_variable and std::mutex and anything else the C++11 libraries can do for us.

Cool, sounds like we're in agreement then!