[LLVMdev] compiler-rt CMake build

[Greg Fitzgerald]

The trouble is that the sanitizer tests are not really compiler-rt
tests.  The original compiler-rt tests are, but not the sanitizer
tests.  The sanitizer tests are "compiler-rt tests via clang".  The
sanitizer runtime is a C++ library requiring only a C++ compiler to
build it (and to *unit* test it).  The ASan lit tests, however,
require clang, because they are testing those C++ functions in the
context of a particular C/C++ compiler's instrumentation.  I believe
these tests should not be called "compiler-rt tests".  They are clang
tests.  In fact, they are just-built-clang tests.  They don't, for
example, verify the C++ library is useful to another compiler, another
version of clang, or simply as a C++ library.  They are integration
tests (tests clang+asan), as opposed to unit tests (tests only the
asan runtime).

I understand that the integration tests are more relevant to the
sanitizers than they are clang, and so it make sense to me that they
reside in the compiler-rt repo alongside the sanitizers.  But rather
than build them in the compiler-rt build, I think the directory should
be exported so that clang can optionally import it.  The clang build
can then add those tests to the clang tests suite, and install the
runtime in whatever location is most appropriate for clang.

Why is this important now?  The CMake developers are trying to make
the LLVM toolchain easy to build for package managers.  Compiler-rt's
dependency on the just-built-clang makes that difficult.  Without that
dependency, Compiler-rt could be built and tested against only an LLVM
package.  And likewise, a Clang package would depend on Compiler-rt
(and do further testing on compiler-rt with those lit tests).  But
with the dependency on the just-built-clang, there needs to be an
additional top-level package, let's call it ClangAndFriends.
ClangAndFriends would depend on Clang and Compiler-rt.  Compiler-rt
would depend on the Clang package as well.  Once both are built,
ClangAndFriends would copy the Clang install directory and then copy
the Compiler-rt install directory into it.  This extra package and
extra copy would be unnecessary if the Compiler-rt build dropped its
dependency on the just-built-clang.  After testing the sanitizers, the
Clang package would copy the runtime into its own install directory.

So what next?  Wait for Brad King's LLVM patches to be integrated.
Then we tweak the compiler-rt build to optionally build against the
LLVM install directory (instead of in the context of the LLVM source
directory).  Next, we use CMake to export the Sanitizer lit tests.
Lastly, Clang optionally imports the test suite and adds the sanitizer
runtime to its install directory.  What do you think?  Squeaky clean?

Thanks,
Greg



On Wed, Feb 5, 2014 at 12:55 AM, Alexey Samsonov <samsonov at google.com> wrote:
>
> On Tue, Feb 4, 2014 at 10:17 PM, Greg Fitzgerald <garious at gmail.com> wrote:
>>
>> Regarding Brad King's CMake patches for LLVM:
>>
>>   http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/173517
>>
>> If compiler-rt could follow suit, the packaging for the toolchain
>> becomes a nice, clean package-manager-friendly DAG.  Currently, the
>> compiler-rt CMake build depends on the just-built-clang to run its
>> test suite.  It's more intuitive to me that either:
>>
>>  1) compiler-rt's sanitizer tests would live inside the clang project
>>  2) compiler-rt would export a test suite that clang could optionally
>> import
>>
>> The former is simpler, but the latter allows the compiler-rt
>> developers to retain control over those tests, which are typically
>> updated alongside changes to compiler-rt's sanitizers.  Thoughts?
>
>
> I'm pretty sure the compiler-rt tests should live in the compiler-rt
> project. You're right:
> these tests should generally be updated in sync with the runtimes. I'm fine
> with creating
> a large test suite comprising all individual tool-specific test suites we
> have now. I'm not
> sure how we can "export" this to clang, though, and why the current
> situation is bad.
>
>
>>
>>
>> Thanks,
>> Greg
>
>
>
>
> --
> Alexey Samsonov, MSK