This is an archive of the discontinued LLVM Phabricator instance.

[sanitizer] Support compiler-rt builtins
ClosedPublic

Authored by phosek on Jul 7 2017, 5:49 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

phosek created this revision.Jul 7 2017, 5:49 PM
phosek updated this revision to Diff 105734.Jul 7 2017, 10:36 PM
mcgrathr accepted this revision.Jul 21 2017, 11:52 AM

This is working well for me.

This revision is now accepted and ready to land.Jul 21 2017, 11:52 AM
alekseyshl added inline comments.Jul 21 2017, 2:35 PM
CMakeLists.txt
97 ↗(On Diff #105734)

Maybe a bit more specific name and comment, SANITIZER_USE_COMPILER_RT_BUILTINS

228 ↗(On Diff #105734)

Add dot at the end

237 ↗(On Diff #105734)

append_list_if(COMPILER_RT_HAS_LIBC c SANITIZER_COMMON_LINK_LIBS)

and we will not have to do it in every single sanitizer

phosek updated this revision to Diff 107760.Jul 21 2017, 5:13 PM
phosek marked 3 inline comments as done.
phosek added inline comments.
CMakeLists.txt
97 ↗(On Diff #105734)

I agree it's not be best name, but it's consistent with the name we use in other runtimes (libc++, libc++abi, libunwind) which will hopefully allow us to set <runtime>_USE_COMPILER_RT=ON reducing some of the boilerplate.

This revision was automatically updated to reflect the committed changes.
phosek reopened this revision.Jul 25 2017, 11:47 PM
This revision is now accepted and ready to land.Jul 25 2017, 11:47 PM
This revision was automatically updated to reflect the committed changes.
eugenis edited edge metadata.Jul 28 2017, 2:57 PM

I'm not yet sure it is caused by this change, but I see that ASan runtime library built for Android now depends on __extendsftf2 among other symbols, and nothing on Android exports that.

phosek added a comment.EditedJul 28 2017, 3:11 PM

I'm not yet sure it is caused by this change, but I see that ASan runtime library built for Android now depends on __extendsftf2 among other symbols, and nothing on Android exports that.

This regression was caused this change, not D34501, but I'm still trying to pinpoint the issue.

I think that this is broken for multilib (-m32 + -m64 builds, the default one for NetBSD, Linux, FreeBSD and maybe others):

-- Found compiler-rt builtins library: /usr/local/lib/clang/7.0.0/lib/netbsd/libclang_rt.builtins-x86_64.a

This ends up in a build failure:

/usr/bin/ld: i386:x86-64 architecture of input file `/usr/local/lib/clang/7.0.0/lib/netbsd/libclang_rt.builtins-x86_64.a(udivdi3.c.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/local/lib/clang/7.0.0/lib/netbsd/libclang_rt.builtins-x86_64.a(udivmoddi4.c.o)' is incompatible with i386 output

Executed command with make VERBOSE=1:

http://netbsd.org/~kamil/llvm/rtlib-32.txt

Everything seems fine except hardcoding libclang_rt.builtins-x86_64.a as noted in CMakeCache.txt:

//Dependencies for the target
clang_rt.asan-dynamic-i386_LIB_DEPENDS:STATIC=general;/usr/local/lib/clang/7.0.0/lib/netbsd/libclang_rt.builtins-x86_64.a;general;c;general;execinfo;general;rt;general;m;general;pthread;

//Dependencies for the target
clang_rt.asan-dynamic-x86_64_LIB_DEPENDS:STATIC=general;/usr/local/lib/clang/7.0.0/lib/netbsd/libclang_rt.builtins-x86_64.a;general;c;general;execinfo;general;rt;general;m;general;pthread;

How to fix this?