[PATCH] [ASan] Fixed path to Android bin directory

[Greg Fitzgerald]

Here's the error I ran into:

Release+Asserts/bin/clang -fno-exceptions -fPIC -funwind-tables
-Illvm/projects/compiler-rt/lib -Illvm/projects/compiler-rt/include
-Wall -Werror -O3 -fomit-frame-pointer -fPIC -fno-builtin -target
arm-linux-androideabi --sysroot=../out/android-toolchain/sysroot
-B../out/android-9-toolchain -mllvm -arm-enable-ehabi -fno-rtti
-fno-vectorize-loops -marm -c -o
tools/clang/runtime/compiler-rt/clang_linux/asan-arm-android/arm-android/SubDir.lib__sanitizer_common/sanitizer_linux_libcdep.o
llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc
projects/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cc:159:5:
error: use of undeclared identifier '_Unwind_Backtrace'
    _Unwind_Backtrace(Unwind_Trace, this);
    ^

Seems the top-level directory has an unwind.h that doesn't include
_Unwind_Backtrace.  A bad solution (my patch) is to add that /bin to
the -B parameter, bypassing all those headers, but leading us to that
-lgcc error and needing to add a -L flag for it.


I built the android toolchain by following this shell script:

http://src.chromium.org/viewvc/chrome/trunk/src/tools/clang/scripts/update.sh?revision=HEAD&view=markup

So instead of applying this patch, to get ASan to compile and link
successfully, I needed to build the android toolchain *without*
--stl=stlport.  Will this cause other problems?  How is it that the
chromium automation isn't failing with the same error?

Thanks,
Greg




On Fri, Oct 11, 2013 at 10:10 AM, Greg Fitzgerald <garious at gmail.com> wrote:
> Evgeniy, Renato,
>
> Thanks for your replies.  You guys are correct.  My patch is no good.
> Sorry for the noise.
>
> -Greg
>
>
> On Fri, Oct 11, 2013 at 2:09 AM, Evgeniy Stepanov
> <eugeni.stepanov at gmail.com> wrote:
>> After reading the doc some more, I think it tries to say that -B
>> values are translated verbatim to -isystem, -L and also prepended to
>> binary paths, which means users must specify multiple -B options for
>> all interesting directories.
>>
>> But in this case we only care about clang, which seems to find
>> everything (on my machine) with a single -B option pointing to the
>> root of the toolchain. Greg, could you figure out why this does not
>> work for you?
>>
>>
>> On Fri, Oct 11, 2013 at 1:06 PM, Renato Golin <renato.golin at linaro.org> wrote:
>>> On 11 October 2013 10:02, Renato Golin <renato.golin at linaro.org> wrote:
>>>>
>>>> which would imply that the "/bin" should be passed. And since
>>>> "/usr/lib/gcc" is there the libraries live, not the binaries, I think that
>>>> part of the manual is just wrong. Possibly copy&paste error?
>>>
>>>
>>> Ok, I think we both got it wrong, Greg. Evgeniy is right.
>>>
>>> This is not the path for other toolchain binaries, but
>>> binaries/libraries/headers for the compiler itself (like lto-wrapper for
>>> gcc).
>>>
>>> So, what you want is to change the binary discovery mechanism when looking
>>> for the android toolchain.
>>>
>>> cheers,
>>> --renato
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits