[llvm-commits] [PATCH][ASan] CMake build rules for ASan/Android runtime.

Evgeniy Stepanov eugeni.stepanov at gmail.com
Tue Aug 28 02:32:25 PDT 2012


Actually, the way I expect this change to work is quite similar to
what you describe, modulo the "recurse" bit. This is how I build it:
mkdir build; cd build
cmake ..
make
mkdir android; cd android
cmake -DCMAKE_CXX_COMPILER=`pwd`/../bin/clang++
-DLLVM_ANDROID_TOOLCHAIN_DIR=$HOME/android-ndk-r8b/standalone ../..
make clang_rt.asan-arm-android
# manually copy the library to the enclosing tree

This can and should be automated.

Note that we have some add_custom_command madness in liba/asan/tests
that can also be converted to "subprojects".

On Tue, Aug 28, 2012 at 11:42 AM, Chandler Carruth <chandlerc at google.com> wrote:
> So, I'm OK with this going in, but I'd appreciate some more severe comments
> around it to warn people away -- we simply can't push this hack much
> further.
>
> I think to do more extensive cross builds we'll need to actually set up a
> cross-compilation environment for LLVM+compiler-rt (not necessarily Clang).
> CMake has "support" for this, but it is awkward and cumbersome. I'm not even
> an expert in how to use it. My understanding is that you configure a
> completely separate cmake build tree and supply it a special input file that
> describes how to proceed with target != host.
>
> My current best idea for how to support this long term is as follows:
>
> We add to CMake the ability to "recurse". the compiler-rt build system would
> automatically populate the target configurations for the runtime libraries
> where target == host, but would also have build rules that would create a
> new, separate build tree *underneath* the existing build tree, automatically
> configure cmake within that tree to use the same source tree location, but
> with a particular target that the current host supports cross-compiling to.
> Then we recurse into this inner mini cmake build system to produce the key
> runtime libraries (and any target-executing binaries they require like the
> symbolizer, and any libraries those depend on).
>
> This way, we can accumulate automatic minimal cross-build configs and setups
> in the project, and if you install the appropriate toolchains and SDKs, you
> can pass a flag to the top level build and it will enable recursing to
> produce certain extra traget outputs.
>
> Anyways, this is quite a bit of work, and while I firmly believe it to be
> necessary in the long term, as the android stuff is still a bit
> experimental, I'm happy to have it unblocked. My suspicion is that you'll
> have to resolve this the moment the symbolizing stuff progresses.
>
>
> On Mon, Aug 27, 2012 at 7:30 AM, Alexey Samsonov <samsonov at google.com>
> wrote:
>>
>> +cc chandlerc
>>
>> LGTM.
>> We'd soon certainly need to generalize CMake rules for building for
>> several targets, though.
>>
>> On Mon, Aug 27, 2012 at 5:55 PM, Evgeniy Stepanov
>> <eugeni.stepanov at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> this is a first pass at cmake (cross-)build of ASan runtime for
>>> Android. The result does not run, but will be useful for catching
>>> build breakage, at least. I'll improve it incrementally.
>>>
>>> https://codereview.appspot.com/6475069/
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>>
>>
>> --
>> Alexey Samsonov, MSK
>>
>



More information about the llvm-commits mailing list