similar to: instrumenting read and write

On Tue, Jun 27, 2017 at 6:00 PM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Tue, Jun 27, 2017 at 4:18 PM, Nischai Vinesh > <nischai.vinesh at gmail.com> wrote: >> Hello, >> >> I have written a custom pass to do some tasks and I want to run this pass on >> a source code file along with TSAN instrumentation. >> >> Steps I followed:

On Tue, Jun 27, 2017 at 4:18 PM, Nischai Vinesh <nischai.vinesh at gmail.com> wrote: > Hello, > > I have written a custom pass to do some tasks and I want to run this pass on > a source code file along with TSAN instrumentation. > > Steps I followed: > 1. I compiled the code file with -fsanitize=thread and -emit-llvm to get the > byte code of the file > 2. Used

I think the code is not getting instrumented with tsan at all. In the 'step 3', when I instrument it using 'opt -tsan ...', it gives a warning "WARNING: You're attempting to print out a bitcode file." I guess this method doesn't instrument the code. Is there any other way I can instrument the code with tsan? On Monday, July 10, 2017 at 7:21:28 AM UTC+2,

On Sun, Jul 9, 2017 at 3:50 PM, Nischai Vinesh <nischai.vinesh at gmail.com> wrote: > Hello, > > I tried that as well but there are no tsan warnings thrown at run time, even > though there are data race error! > > The steps I followed: > 1. Generate bitcode using 'clang -emit-llvm' command > 2. Using the 'opt -load ..' command, I instrumented the

Hello All, I am trying to write llvm pass to instrument function in external library. I am using clang to automatically load my pass. I have test.cpp which calls functions in library testlib.so. I have written llvm pass to instrument all reads and writes in test.cpp and call function(recordRW) in testlib.so. this is how my pass looks like - for (auto &BB : F) { for (auto &I : BB)

I am sorry to not make my question clear. My question is how this value is calculated without having fadd and fsub in IR? On Sat, Aug 11, 2018 at 4:06 PM, Craig Topper <craig.topper at gmail.com> wrote: > Neither 1e16 or 1e16+1 can be accurately represented in a double. The > largest integer than be accurately represented is 2^53. As the number gets > larger floating sacrifices

Hi Alex, + Galina Ubuntu/Debian should work as well, I wanted one flavor where lld could be built on linux platform. I will want to have a seperate buildbot to seperate failures if any due to the fsanitize options. 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. Thanks Shankar Easwaran On 9/8/2013 10:22

Hi Steven, This looks interesting and raises a number of questions :) 1) Does applying this patch actually bring working sanitizers to x32 platform? That is, after you build the clang, does "clang -fsanitize=whatever foo.c" compile/link/run with expected results? I doubt that, as there is some platform-specific code in all the sanitizers, and many of them heavily depend on the address

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

Do you pull clang under llvm/tools and compile it as well? In theory, if `opt` recognize the option, so does `clang -mllvm`. 2018-01-12 8:47 GMT+08:00 sangeeta chowdhary <sangitachowdhary at gmail.com>: > Hello, > > I have tried giving this option like this > > clang -c -emit-llvm -mllvm -rdetector hello.c -c -o hello.bc > but I am getting error " Unknown command

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

There are existing Darwin and Win7 builders, and a few Debian configs that also build lld. I'd support enabling the sanitizers on these builds as is. Also, tsan especially because lld uses threads. If you'd like an Ubuntu bot, somebody is going to have to provide one. Alex On Sep 6, 2013, at 2:27 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi All, Chandler, >

(though, usual caveat: you /usually/ shouldn't be doing that - instead relying only on whatever semantics the IR actually carries, rather than implying extra semantics based on the demangled name) On Wed, Jun 24, 2020 at 12:48 PM Johannes Doerfert via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I have not tried it but maybe > > `std::string llvm::demangle(const

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

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

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, The LangRef warns that "blockaddress(@function, %block)" has a limited and target-dependent applicability: https://llvm.org/docs/LangRef.html#addresses-of-basic-blocks But I wanted very much to save addresses of blocks in a global variable and so I did: % cat cond.c void foo(long *a) { if (a) *a = 0; } % clang -O1 -c cond.c -fsanitize-coverage=inline-8bit-counters,pc-table -S

Hello, We're evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int

Hi, I'm looking for a way to add instrumentation that handles all function arguments, one by one. With variable argument lists, this can only be done at the place of va_arg() call. Unfortunately, Clang lowers va_arg into platform-specific code in the frontend, and I can't find a good, reliable way to figure it out in our LLVM pass. I've tried adding a special case of TBAA info to the

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