similar to: Memory sanitizer porting

Hi, 1. This patch adds an internal (-mllvm) option, which is basically meant for debugging. If your custom platform has a target triple, you could submit changes to llvm, clang and compiler-rt to specify any platform-specific offsets and other details. 2. Blacklist is meant to disable checking for bugs in certain functions, not to remove all instrumentation. With ASan, these are the same. With

Hi, 1. No, there is no custom triple for the platform. It currently uses Linux triple, and I do not think there is a possibility of upstreaming not so many changes in such a way. On the other side Apple uses the mllvm asan option to implement KASAN in XNU, so I think it will be fine to upstream a similar option, which I guess, could also be used for debugging, and may be helpful to other people

Hello, I'm quite new to LLVM, but I'm interested in memory sanitizer. The petty thing is, that 32bit addressing on Linux is not supported. Thus I tried to take the latest version of the software and to modify it, using Ubuntu 16.04 as operating system. Given the example example.c: #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { int *a = (int

I updated one of my powerpc64le llvm test systems to Fedora 25 and I started getting a whole bunch of sanitizer test case failures. I tried testing some earlier revisions on the new OS that had worked fine under the old but they generate the same errors now so it isn't any changes in llvm. There are two different errors: FATAL: ThreadSanitizer: unsupported VMA range FATAL: Found 47 -

Hi there, I'm trying to use the memory sanitizer of LLVM 3.3. It's crashing during MSan initialization (__msan::InitShadow). Here's the strace output. mmap(0x400000000000, 35184372088831, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x400000000000 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x55edf4b36720} --- +++ killed by SIGSEGV (core

Aside: would it be useful to execute a build of the libc++/libc++abi with msan normally during release, and change the driver to look for these msan-built C++ libs when "-fsanitize=memory"? That would drastically cut down on the complexity of using msan. On Fri, Aug 31, 2018 at 5:43 AM Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks Vitaly and

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

I ran "ninja check-asan" and no errors. But "ninja check-msan" had 117 errors. I took the first FAILED test, which was for eventfd.cc, and executed the command line creating an eventfd executable in a temporary directory and then executed that file using gdb. Finally, used bt to dump the stack. I've emailed llvm-admin at lists.llvm.org to setup an account since

Does it build with libstdc++? I've got this with fresh clang, -std=c++11: In file included from ../projects/lld/lib/ReaderWriter/ELF/./SectionChunks.h:19: In file included from ../projects/lld/include/lld/Core/Parallel.h:28: In file included from /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/condition_variable:38:

Another option is just to run corresponding script from *https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/ <https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/>* in empty directory. On Thu, Aug 30, 2018 at 5:00 AM Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Dean, > > I've not done this

X32 support patch for compiler-rt. Applies against current trunk. --- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21 06:27:38.000000000 +0000 +++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21 11:16:55.891621025 +0000 @@ -41,7 +41,18 @@ SupportedArches += x86_64 endif else - SupportedArches := x86_64 + # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit

FYI We have an upstream bootstrap bot ( http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap) that does a number of things including running llvm/clang tests under ASan/MSan. Probably we can add a couple of steps that would checkout lld and run check-lld in ASan-ified/MSan-ified build trees. On Mon, Sep 9, 2013 at 9:00 AM, Shankar Easwaran <shankare at codeaurora.org>wrote:

Hi Evgeniy, Can you add the step to checkout lld and build and run the unittests then ? Thanks Shankar Easwaran On 9/10/2013 4:59 AM, Evgeniy Stepanov wrote: > Does it build with libstdc++? I've got this with fresh clang, -std=c++11: > > In file included from ../projects/lld/lib/ReaderWriter/ELF/./SectionChunks.h:19: > In file included from

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

On 11 February 2016 at 17:08, Reid Kleckner <rnk at google.com> wrote: > On Thu, Feb 11, 2016 at 5:53 AM, Dan Liew via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> > Can you somehow verify that this heap-use-after-free is happening? >> > E.g. print all the pointer values coming from memory::allocate, coming >> > into >> >

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

On 9/8/2013 11:48 PM, Chandler Carruth wrote: > On Sun, Sep 8, 2013 at 9:29 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Do you know if llvm itself gets tested as a complete build with the >> fsanitize options ? >> >> Enabling tsan seems to be a good idea too. >> > We test it very regularly with all of the sanitizers. We've not been

Hi, Currently the first stage ("run sanitizer tests in gcc build") of the sanitizer-ppc64-linux1 buildbot is only failing because of: + cd clang_build + make -j16 check-lsan make: *** No rule to make target `check-lsan'. Stop. + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ + cd clang_build + make -j16 check-msan make: *** No rule to make target `check-msan'. Stop. + echo

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the