[LLVMdev] Building sanitizers for Android

[Greg Fitzgerald]

Sorry for the slow replies.  I'm out on vacation this week.


Alexey wrote:
> If you want to test the sanitizer runtiume library "during development",
> you should verify that it works with the Clang at hand.

I want to test an implementation of libraries, not that clang links a
library in its install directory.  We only need one clang test for the
latter (not 100) and that test already exists in the clang test suite.


> Sanitizer runtime and the compiler are tightly
> coupled, why would you want to test the former in isolation?

They aren't that tightly-coupled though.  There's an interface and an
implementation.  That interface rarely changes relative to the number
of changes to the implementation.

https://github.com/llvm-mirror/compiler-rt/commits/master/include/sanitizer
https://github.com/llvm-mirror/compiler-rt/commits/master/lib


> Modifying Clang driver for testing-only purposes, especially for testing in a non-default
> configuration doesn't sound good to me.

Agreed and that's not what's happening.  The optional part is adding a
-L flag to the invocation of clang within the compiler-rt test suite.
If using the monolithic build, those flags are not added and clang
finds the libs via its hardcoded '-L' flag.


Yury wrote:
> It's not that easy. Some tests require passing environment variables

As Evgeniy mentioned, it's a short enough list of variables that you
can whitelist them.  LD_PRELOAD, LD_LIBRARY_PATH, ASAN_OPTIONS, etc.


Evgeniy wrote:
> Greg, do you copy binaries to the device on %clang or on %run?

%run.  Can you point me to a case where you needed to override %clang for that?

Thanks,
Greg

On Mon, Apr 21, 2014 at 12:54 AM, Evgeniy Stepanov <eugenis at google.com> wrote:
> Both %run and my symlink approach add certain (yet undocumented)
> requirements on the tests, but they should be 100% robust if those
> requirements are followed.
> Greg, do you copy binaries to the device on %clang or on %run? The
> latter would miss shared libraries that are not executed directly.
> Environment can be recreated on the device, my script attempts to do
> it (for several whitelisted variables).
> We don't preserve ulimit setting, I modified one or two tests to not
> rely on that.
>
> I don't mind switching to a combined approach - copy to device on
> %clang, and replace symlink hacks with %run.
>
>
>
> On Mon, Apr 21, 2014 at 9:09 AM, Yury Gribov <y.gribov at samsung.com> wrote:
>>> We considered adding "%run" to all binary invocations,
>>> but dropped this idea. I don't remember the details, but IIRC %run is
>>> just not general enough.
>>
>>
>> IMHO this is where simplicity of lit approach starts to fail - important
>> information (environment variables, dependent shared libs, expected test
>> status, etc.) is buried inside arbitrarily complex runstrings.
>>
>> -Y