similar to: Sanitizers + New Pass Manager

Just tested it out, that test does indeed fail under the old PM at -O3 and even at -O2. If the ASan pass runs after optimizations and is designed to detect undefined behavior at runtime, I don't see how it can be super reliable at higher optimization levels. On Wed, May 13, 2020 at 12:39 PM David Blaikie <dblaikie at gmail.com> wrote: > +some sanitizer/new pass manager folks >

On 5/13/20 3:31 PM, David Blaikie via llvm-dev wrote: > I believe it's meant to run after /some/ optimizations to make it a bit > more efficient, while not so optimized that it misses opportunities to > detect bugs - but I could be wrong there. I'll leave it up to other folks > to chime in. I think that is right. The more transformations you run the more UB you can also

On 5/14/20 5:33 AM, Arthur Eubanks via llvm-dev wrote: > > Is it the case that with the legacy PM there is no inlining at > either -O2 or -O3 and with newPM there is? Or is there something else > going on? > Legacy PM inlines at -O2/-O3, new PM inlines at -O1/-O2/-O3. These > cases where inlining occurs also coincide with the test failure. I > agree that inlining itself

Sanitizer passes really should not run before the inliner. For example, ASan moves all allocas into a "mega-alloca" to obtain fixed frame layout for reporting purposes. It also inserts a fake stack check in the function prologue which will get duplicated (but will probably still work) after inlining. MSan removes readnone/readonly from all functions because they all update shadow which

Hi all, TL;DR 1) We should change the way we parse common runtime flags in sanitizers. 2) We should make ASan aware of the tools it can be combined with (LSan and UBSan). 3) We may have to restrict the tools UBSan can be combined with (currently to ASan) (see [1]) Currently we have two kinds of sanitizer runtime flags: tool-specific flags and "common flags", defined in sanitizer_common

On Mon, Dec 8, 2014 at 2:00 AM, Alexander Potapenko <glider at google.com> wrote: > Hope you're assuming there's always a single copy of common_flags in > the process. > This isn't the case for e.g. ASan+UBSan on Mac, but that's a broken setup. > > What if we let the tools protect specific flags (by adding a bool to > each flag) once they set their values

On Fri, Jan 31, 2014 at 1:47 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 31 January 2014 08:50, Alexey Samsonov <samsonov at google.com> wrote: > >> That is, I still don't see what the problem is - it's relatively easy to >> enable building just the compiler-rt library on ARM and not enable building >> sanitizers on ARM. >> > >

That's excellent! I think the check-sanitizer target should cover it. Thanks, Hans On Fri, Feb 22, 2019 at 1:34 PM Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Hans, > > I have a freebsd machine and some time to spare this weekend. > > Could you offer the minimal git bisect command to repro? I'm hoping not to have to run the full check-clang test suite if

Hi LLVM people, Not sure whether this is the best place to ask this. Given the source of a program, I would like to detect both uninitialized reads and out-of-bounds memory accesses. The latter can be done with the Address Sanitizer (ASan) and the first using the Memory Sanitizer (MSan). Is there a way to use both at the same time? The --fsanitize option only seems support one of these. What is

> On Feb 17, 2015, at 4:00 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > > > On Tue, Feb 17, 2015 at 3:37 PM, Anna Zaks <ganna at apple.com <mailto:ganna at apple.com>> wrote: > Unfortunately, we do rely on the Autotools to build for darwin. > > The lack of proper testing is very unfortunate. In the future, we will either drop the dependency on

> By the way, locally, I now have just over half the ASan test suite > passing ARM-Linux via QEMU. Greg, Do you mean that you've added support for QEMU-based testing to sanitizer CMakeLists? That would be super-cool. -Y

> 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

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

Many thanks for digging into this, and sorry for my slow reply. Kamil: it sounds like your commit is involved here. Any idea what's happening? Dimitry: If we don't find anyone to debug and fix this before the release, how bad is it for FreeBSD? Can it be worked around downstream if 8.0.0 ships without a fix? Since I'm not entirely sure how supported this functionality is on FreeBSD,

> 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

> 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

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

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

The build for the Android sanitizers is unique in that it needs to link against the Android system libraries to create a shared object and its test suites. The current solution to build ASan is to drop the compiler-rt repo into the llvm source tree and cross-compile the llvm build for Android. This is a bit awkward for few reasons: 1) Not all of llvm can be cross-compiled for Android.

I think the release is looking pretty good, but there is one blocker that's worrying me: https://llvm.org/PR40761 >From what I understand, ASan et al. used to work on FreeBSD but don't anymore, and there's nobody working on it. Is there someone who has access to a FreeBSD machine that could help investigate this? Just getting it bisected would be super helpful. Thanks, Hans