similar to: [LLVMdev] [Compiler-RT] ARM build fails with unknown argument

I'm getting this link failure when running ninja check on Linux. I'm configuring with shared libraries enabled, so I'm not sure why asan is looking for .a archives. $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON -DCLANG_INCLUDE_DOCS=ON -DBUILD_SHARED_LIBS=ON ../llvm $ ninja check-all FAILED: cd [..]bld/projects/compiler-rt/lib/asan/tests &&

+Alexey On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> wrote: > > I'm getting this link failure when running ninja check on Linux. I'm > configuring with shared libraries enabled, so I'm not sure why asan is > looking for .a archives. > > $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON > -DCLANG_INCLUDE_DOCS=ON

Looking On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > +Alexey > > On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> I'm getting this link failure when running ninja check on Linux. I'm >> configuring with shared libraries enabled, so I'm not sure why asan is >>

Hi, I'm trying to run the ASAN tests on ARM (to fix the CMake RT bot we have) and I'm hitting a different bug on my Chomebook than I have on the bots: [6/32] Generating ASAN_INST_TEST_OBJECTS.asan_interface_test.cc.arm-inline.o ... clang-3.6: warning: argument unused during compilation: '-march=armv7-a' clang (LLVM option parsing): Unknown command line argument

Hello, There is a problem in the compiler-rt project regarding a new change I need to make. The change is that in extended gcc syntax, when the same register is in the input/output list and in the clobber list, there is a conflict and llvm should produce an error. Until now, it didn't produce an error. In compiler-rt's tests, there's a test which shouldn't generate an error but

Fixed by LLVM r262063, thanks for reporting this! On Fri, Feb 26, 2016 at 11:35 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Looking > > On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > >> +Alexey >> >> On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> >> wrote: >>

On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com > wrote: > On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at gmail.com> > wrote: > > Hi, > > > > I consider reducing the usage of blacklist in sanitizer instrumentation > > passes and doing the necessary work in frontend (Clang) instead. > > > > Some

Hi Evgeniy, I just created a new buildbot that compiles and tests compiler-rt together with LLVM/Clang using the CMake build: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/0 There are a few ASan failures and I'd like to check with you which of them are real failures that we need to fix and which are just unsupported / noise. These tests are running on an ARMv7

Hi, I consider reducing the usage of blacklist in sanitizer instrumentation passes and doing the necessary work in frontend (Clang) instead. Some of it is already implemented: e.g. Clang will attach an attribute "sanitize_address" to function definition only if this function is not blacklisted. In this case we won't instrument the memory accesses in this function in ASan

Hi, I'm not sure what's up with BuiltinLongJmpTest. I think Greg was the last to do anything about arm-linux support in asan. As for the aarch64 failures, do you want to build the aarch64 bit stuff, but not run the tests? In cmake we try to detect target platforms supported by the compiler, but we don't check that binaries actuall run. But why is there so little failures, if the

On 10 October 2014 15:30, Evgeniy Stepanov <eugenis at google.com> wrote: > Could this be some kind of linker-generated compatibility magic? I'm not sure. Searching for "____asan_handle_no_return_veneer" on Google gets me this thread. :) I'm tempted to disable that test on ARM+Linux, since we use EHABI instead of SjLj... At least for now... --renato

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*

Hi, we plan to remove -fsanitize-address-zero-base-shadow command line flag from clang, and disable zero-base shadow support on all platforms where it is not the default behavior. - It is completely unused, as far as we know. And completely undocumented, too. - It is ABI-incompatible with non-zero-base shadow, which means all objects in a process must be built with the same setting. Failing to

I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin

On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> >> A recent change added defined(__linux__) condition to the code below. >> Now it says that on linux with --std=c++0x (or --std=c++11) the system >> stdlib.h header

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

On 7 October 2014 20:55, Evgeniy Stepanov <eugenis at google.com> wrote: > Can you elaborate on this? Does it ever clean those lines? These > numbers are correct on multiple other platforms. I wonder if it's some > codegen peculiarity that leads to this off-by-one mistake? Can you go > down to the individual compile/run invocation and verify that line > numbers match (or

Thanks, it works. 2.15 has quick_exit and at_quick_exit. The attached patch also works. On Mon, May 13, 2013 at 11:22 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > > On Mon, May 13, 2013 at 11:16 AM, Kostya Serebryany <kcc at google.com> wrote: >> >> __GLIBC_PREREQ(2, 17) > > > Attached patch should work. Please test. > > Regards. >

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

Hi Evgeniy, Yes, it is. The problem here is that the program doesn't fail on my box (release and debug builds), so I have no idea how to debug the problem. According to the test, it's ran as "not chained_origin_with_signals.cc.tmp", expecting it to fail. Also, the FileCheck expects to find warnings on the output, for which there is none Maybe I'm missing some CMake flag or