similar to: [LLVMdev] setrlimit vs ulimt

> execv(argv[0]) is a canonical way to restart the > process, it's sad that the emulator interferes with that. We have the option to emulate the instruction set or emulate the OS. The former is lighter weight and easy to configure. The downside is that system calls route to the host system. That can be useful if, for example, the executable invokes llvm-symbolizer. While

> Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not? Because the llvm-symbolizer the runtime finds is built for the host architecture. This is weird, yes, but once we integrate the symbolizer, it goes away. > Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary > %run %ulimit -s 8192 %t? I like that idea. How

> This is a public interface. But ASan runtime (and test-suite) strongly depends on > the instrumentation pass in Clang. How do you feel about adding a runtime init check of a version number defined by asan_interface.h? -Greg On Tue, Apr 22, 2014 at 11:16 AM, Alexey Samsonov <samsonov at google.com> wrote: > > On Tue, Apr 22, 2014 at 10:43 AM, Greg Fitzgerald <garious at

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

It does sound like Android is better suited for "honest" cross-compilation, rather than "build compiler-rt for all targets we can find" model. I'm still not convinced that we must require the "ninja install" step. Could we just "ninja clang" and then build the second stage against the first stage build directory? Will this "find_package" thing

Hi Greg, On Wed, Apr 2, 2014 at 2:50 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Alexey, Evgeniy, > > I propose the following steps to unify multi-arch support in compiler-rt: > > 1) The compiler-rt test suite adds "-L${CMAKE_CURRENT_BINARY_DIR}/lib" > to its 'clang' variables. This way we can test the sanitizers without > installing any libs

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

Alexey, >> Some good news, the drivers (both gcc and clang) allow us to put the >> '-L' parameters after the '-l' parameters. I made these changes locally and it went really well. The patch to clang is quite small and only one unit-test needed updating. In compiler-rt, I updated the flags passed to clang to include a '-L${COMPILER_RT_BINARY_DIR}/lib' and

> Note that ASan tests on Android require llvm-symbolizer binary. That's a really good point. And I see that llvm-symbolizer can't just be pulled into compiler-rt because it has dependencies on DebugInfo, Object, and Support libraries. This throws a big wrench in Alexey's plan to have the native compiler-rt build generate the cross-compiled binaries for all supported targets. We

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

On Thu, Apr 3, 2014 at 9:23 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > I don't think it's a good idea to let user hijack > > the driver and stuff in custom version of > > ASan runtime instead the one installed/built > > with compiler :) > > I'm okay with it. This is open source. If someone wants to put the > sanitizers on a shorter

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

On Thu, Apr 3, 2014 at 5:04 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > we would still want to use compiler-rt test-suite in a standalone mode, > to test fully built/installed toolchains, > and even GCC. > > Sounds good. > > > > Clang driver links the static xsan runtimes from a hardcoded > > paths in Clang resource directory, and doesn't

On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > failing tests I see are in ubsan: > > Failing Tests (6): > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp > UndefinedBehaviorSanitizer ::

> First of all, sorry for the late response (I'm in the process of moving to California). Welcome! > We need to verify that simple command "clang -fsanitize=address foo.cc" works Agreed. The test suite is useful in many different scenarios: 1) Verifying the integrated clang. 2) Verifying the integrated gcc. 3) Verifying the libraries during development. I'm working

For the same reason we use shared runtime on OSX. We intercept libc calls by declaring a function with the same name in the sanitizer runtime library. Glibc loader puts main executable early in the symbol lookup order, which lets us interpose symbols from shared libraries with symbols from statically linked sanitizer runtime. Android (and AFAIK most other platforms) does not allow that, which is

Some updates: First, thanks so much for creating these test suites. Troubleshooting is going very quickly! > There is some flakiness in SanitizerCommon.SpinMutex test. Yes, I'm seeing that too. SpinMutexTry as well. Should these be disabled? > ARM JellyBean works over here. I found a configuration that works well on JB 4.1.2 and 4.2.2. The trick is to build the ASan *runtime*

> Alexey's approach with CMake sub-projects. I prefer that direction as well, but what I've proposed is a solution that works today. To support cross-compilation, we'll need to loop over each supported arch (llvm-config --targets-built), then loop over each supported triple for each arch (hard-coded map?), and then pair up each triple with a sysroot (system paths provided by the

From: http://address-sanitizer.googlecode.com/svn-history/r1624/wiki/Android.wiki > AddressSanitizer is fully supported in AOSP starting with JellyBean release. To run > applications built with ASan you'll need an -eng build of Android. > > To build any part of Android system with ASan, add > LOCAL_ADDRESS_SANITIZER:=true to the appropriate Android.mk. I don't see that

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.