This is an archive of the discontinued LLVM Phabricator instance.

[libc] Add support library for use with tests.
AbandonedPublic

Authored by sivachandra on Feb 14 2020, 2:36 PM.

Details

Summary

We do not want tests to include standard library headers to avoid
name conflicts. This support library helps shield the test compilation
units from the standard library while still providing the flexibility to
use the standard library.

This change adds wrappers for functions std::abort and the unix sleep
functions. It also provides a simple threading utility which is a wrapper
over the C++ std::thread class.

Event Timeline

sivachandra created this revision.Feb 14 2020, 2:36 PM
abrachet added a comment.EditedFeb 14 2020, 5:40 PM

I was actually just working on a patch to add death tests, so I have a lot of thoughts on this :)

We could do something like:

header.h
struct PolymorphicFunction {
  virtual ~PolymorphicFunction() {}
  virtual void call() = 0;
};

void doDeathTest(PolymorphicFunction &);

template <typename Func>
void createPolyFunction(Func f) {
   struct F : public PolymorphicFunction {
      Func f;
      F(Func f) : f(f) {}
      void call() override {
         f();
      }
   };
   F polyFunc(f);
   // For forking death teast stack allocation was fine but for thread we can't do that.
   doDeathTest(polyFunc);
}

So that in tests we can use lambdas, even ones which have a capture. What do you think about something like that? A Thread class could hold PolymorphicFunction * for example.

libc/utils/testutils/Thread.h
14–15

I think these are not very ergonomic because they cannot be instantiated with lambdas. See my top level comment how I think we can do this better.

libc/utils/testutils/linux/sleep.cpp
8

Out of curiosity, why have you added sleep? Where do you think it will be useful?

abrachet added inline comments.Feb 14 2020, 11:14 PM
libc/utils/testutils/Support.h
7

We could just do (outside of the namespaces) extern "C" void abort(); instead of providing this wrapper ourselves.

I'm assuming because sleeps implementation is in a linux directory that it's called something else on Windows?

gchatelet added inline comments.Feb 19 2020, 12:27 AM
libc/utils/testutils/Support.h
6

Do we need sleep in tests? What would be the use case?

sivachandra marked 3 inline comments as done.

Address comments

sivachandra added inline comments.Feb 19 2020, 12:57 AM
libc/utils/testutils/Support.h
7

Agree about abort.

I added sleep so that I can write a stop and go test for a mutex implementation. I think on Windows it is this: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sleep?redirectedfrom=MSDN

libc/utils/testutils/Thread.h
14–15

Inspired by your change, I have updated this now. I did not see a reason to support all possible forms of a callable so I have limited my changes to just that I require for now.

libc/utils/testutils/linux/sleep.cpp
8

Answered above.

Add missing header guards.

Having thought through this patch and its use again, I am currently of the opinion that we should not really be creating equivalents of the library implementations. For example, if we want abort, we should use __llvm_libc::abort. The abort implementation will have its own atomic test and that should be good enough of a confidence to use it in other tests. Likewise, we should be using the __llvm_libc::thrd_create and friends instead of using equivalents build over other libraries. We can choose to employ C++ convenience however - that is, we could implement a thread class using the __llvm_libc::thrd_* functions.

WDYT?

Having thought through this patch and its use again, I am currently of the opinion that we should not really be creating equivalents of the library implementations. For example, if we want abort, we should use __llvm_libc::abort. The abort implementation will have its own atomic test and that should be good enough of a confidence to use it in other tests. Likewise, we should be using the __llvm_libc::thrd_create and friends instead of using equivalents build over other libraries. We can choose to employ C++ convenience however - that is, we could implement a thread class using the __llvm_libc::thrd_* functions.

WDYT?

Yes that makes sense. For readability it's much better as well since there's no ambiguity on which function gets called.

sivachandra abandoned this revision.Feb 28 2020, 1:53 PM

We will not take this route.