<div dir="ltr">Hi Greg,<div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 12:55 AM, Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The trouble is that the sanitizer tests are not really compiler-rt<br>
tests.  The original compiler-rt tests are, but not the sanitizer<br>
tests.  The sanitizer tests are "compiler-rt tests via clang".  The<br>
sanitizer runtime is a C++ library requiring only a C++ compiler to<br>
build it (and to *unit* test it).  The ASan lit tests, however,<br>
require clang, because they are testing those C++ functions in the<br>
context of a particular C/C++ compiler's instrumentation.  I believe<br>
these tests should not be called "compiler-rt tests".  They are clang<br>
tests.</blockquote><div><br></div><div>Well, not really. I agree that there is a significant difference between plain compiler-rt and</div><div>sanitizers:</div><div>1) compiler-rt is more or less a regular C++ library, with the exception that a compiler</div>
<div>sometimes creates a calls into compiler-rt. compiler-rt can be built with any C compiler,</div><div>and can be fairly easy unit-tested.</div><div>2) sanitizer libraries are special in a way that they more heavily rely on compiler instrumentation and</div>
<div>code transformations. sanitizers can be built with any C++ compiler, but "unit-testing" is far</div><div>less important for them, and although we have regular unit tests (that don't expect</div><div>instrumentation) for some sanitizers, we are really more concentrated on testing</div>
<div>compiler+run-time together.</div><div><br></div><div>But our tests (call them "integration tests" or "toolchain tests") are not Clang-specific - they</div><div>should work (and we'd love to make them work) with GCC version of ASan as well. So, in</div>
<div>a perfect world, we would have a "sanitizer-tests" test suite, which we can run with</div><div>any compiler we specify at configuration time, be it just-built Clang, or GCC [1].</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  In fact, they are just-built-clang tests.  They don't, for<br>
example, verify the C++ library is useful to another compiler, another<br>
version of clang, or simply as a C++ library.  They are integration<br>
tests (tests clang+asan), as opposed to unit tests (tests only the<br>
asan runtime).<br>
<br>
I understand that the integration tests are more relevant to the<br>
sanitizers than they are clang, and so it make sense to me that they<br>
reside in the compiler-rt repo alongside the sanitizers.  But rather<br>
than build them in the compiler-rt build, I think the directory should<br>
be exported so that clang can optionally import it.  The clang build<br>
can then add those tests to the clang tests suite, and install the<br>
runtime in whatever location is most appropriate for clang.<br>
<br>
Why is this important now?  The CMake developers are trying to make<br>
the LLVM toolchain easy to build for package managers.  Compiler-rt's<br>
dependency on the just-built-clang makes that difficult.  Without that<br>
dependency, Compiler-rt could be built and tested against only an LLVM<br>
package.</blockquote><div><br></div><div>Why does compiler-rt needs to be tested against LLVM package? All</div><div>compiler-rt runtimes can be built and unit-tested with any C/C++ host compiler,</div><div>if they don't depend on just-built-Clang. Or do you mean LLVM testing</div>
<div>utilities (llvm-lit, FileCheck) here? If yes, maybe it makes sense to move *them*</div><div>to another package as well?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  And likewise, a Clang package would depend on Compiler-rt<br>
(and do further testing on compiler-rt with those lit tests).</blockquote><div><br></div><div>That's a bit weird - what if compiler-rt is not supported on a platform, where Clang is supported?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  But<br>
with the dependency on the just-built-clang, there needs to be an<br>
additional top-level package, let's call it ClangAndFriends.<br>
ClangAndFriends would depend on Clang and Compiler-rt.  Compiler-rt<br>
would depend on the Clang package as well.  Once both are built,<br>
ClangAndFriends would copy the Clang install directory and then copy<br>
the Compiler-rt install directory into it.</blockquote><div><br></div><div>Can we instead make a package SanitizerTests (or whatever)? It won't even</div><div>need to have any dependencies - instead we should make it configurable -</div>
<div>SanitizerTests should take as a parameter a path to the compiler, and use</div><div>it to run the lit-tests and GTest-style unit tests that require instrumentation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  This extra package and<br>
extra copy would be unnecessary if the Compiler-rt build dropped its<br>
dependency on the just-built-clang.  After testing the sanitizers, the<br>
Clang package would copy the runtime into its own install directory.<br>
<br>
So what next?  Wait for Brad King's LLVM patches to be integrated.<br>
Then we tweak the compiler-rt build to optionally build against the<br>
LLVM install directory (instead of in the context of the LLVM source<br>
directory).</blockquote><div><br></div><div>Please note that it makes a lot of sense to built compiler-rt (and sanitizers) with just-built</div><div>Clang. In fact, even though we should support building it with another compilers (gcc, MSVC),</div>
<div>using just-built-Clang should be a default scenario, like it is in configure+make build.</div><div>In this way we'll be able to build compiler-rt libs for platforms that just-build</div><div>Clang can target, and host compiler probably can't...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Next, we use CMake to export the Sanitizer lit tests.<br>
Lastly, Clang optionally imports the test suite and adds the sanitizer<br>
runtime to its install directory.  What do you think?  Squeaky clean?<br>
<br>
Thanks,<br>
Greg<br></blockquote><div><br></div><div>[1] Except that we frequently add new features to sanitizers and modify</div><div>compiler<->runtime interface, so the test-suite is kind of tied to the ToT Clang.</div><div>
But, at the moment we merge Sanitizer runtime into GCC tree at revison X,</div><div>we can cut off Sanitizer testsuite at revision X as well, and expect it to work.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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