similar to: "compiler-rt" - DataFlowSanitizer

I am using pre-built LLVM/Clang 3.8.0 binaries on Ubuntu 16.04.2, 64 bit. I tried to lift a minimal program to LLVM IR, then link the IR to DataFlowSanitizer libraries to produce executable code. In the second step, the process throws a bunch of linker errors. ========================================= #include <sanitizer/dfsan_interface.h> #include <assert.h> int main(void) { int

Hi there. I’m trying to use LibFuzzer on OSX and face some issues: I checked out LibFuzzer documentation[1] and managed to proceed until the final step of the first example. Now I see linker errors related to dfsan, dfsan’s documentation[2] states explicitly “DataFlowSanitizer is a work in progress, currently under development for x86_64 Linux.”. Does it mean that LibFuzzer available only on

Hi, I am starting a thread to discuss the design of DataFlowSanitizer, a compiler instrumentation based analysis tool which I am hoping to bring into LLVM. As a starting point, I have included the current version of the design document below. Comments are appreciated. Thanks, Peter DataFlowSanitizer Design Document ********************************* This document sets out the design for

On Thu, Jun 13, 2013 at 03:00:46PM -0700, Peter Collingbourne wrote: > Hi, > > I am starting a thread to discuss the design of DataFlowSanitizer, > a compiler instrumentation based analysis tool which I am hoping to > bring into LLVM. As a starting point, I have included the current > version of the design document below. Comments are appreciated. Any further comments on the

Can anybody give me any pointer on how compiler-rt, especially the sanitizers work? Do they operate on IR as any other LLVM pass? Or are they integral part of the frontend itself? I couldn't spot any documentation on the internals of compiler-rt project? What happens (sequence of actions) when I pass -fsanitizer=dataflow to clang? Precisely, I intend to alter the behaviour of DFSan to suit my

Hi. I'm using llvm DataFlowSanitizer. I add such code in library libtiff. dfsan_label lt_label = dfsan_create_label("buf_offset", 0); dfsan_set_label(lt_label, (unsigned char *)buf, size); But when i compile libtiff with "-fsanitize=dataflow" option, then there is an error as follows: ../libtiff/libtiff.so.5.2.5: undefined reference to `dfs$jbg_enc_init'

Hi, If there are no further comments on the design below I intend to commit my DFSan patches in a week. Thanks, Peter On Tue, Jun 25, 2013 at 06:13:49PM -0700, Peter Collingbourne wrote: > On Thu, Jun 13, 2013 at 03:00:46PM -0700, Peter Collingbourne wrote: > > Hi, > > > > I am starting a thread to discuss the design of DataFlowSanitizer, > > a compiler

On Tue, Oct 7, 2014 at 2:51 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Looks good, thanks! > > Can you write the test case, please? You probably have more experience > writing debug info tests than I do. > Sure - though how would I get the pre-dfsan .ll file to produce this behavior? I've tried compiling to a .ll file without dfsan, then feeling that .ll

Here's a basic patch which would solve it in sort of the same way as the other optimizations I was fixing (just special case the debug info & fix it up). I can work up a test case for this as well, or you can, if you like/this seems reasonable. On Tue, Oct 7, 2014 at 2:30 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 12:20:55PM -0700, David

On Tue, Oct 7, 2014 at 12:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Oct 7, 2014 at 12:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote:

Hi all, Any one tried using DataFlowSanitizer on Linux x86_64? I tried on: 3.13.0-44-generic #73~precise1-Ubuntu SMP Wed Dec 17 00:39:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It assumes wrong memory layout and remaps application code segment as shadow memory, thus causing SIGSEV (Segmentation fault). Is this know? and fix under way? -Thanks, Aravind -------------- next part

Afternoon, I had an issue with trying to link a program with the DataFlowSanitizer functionality, this is from the libFuzzer project, and I was seeing: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned

FWIW see also http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043301.html As far as I understand DFSan functionality isn't required for libFuzzer to work, so it should be safe to disable DFSan support on Mac. On Wed, Jul 8, 2015 at 7:45 AM, Kostya Serebryany <kcc at google.com> wrote: > +pcc , glider > > On Mon, Jul 6, 2015 at 12:59 PM, Juan Ceasar <juan.d.ceasar at

Dear Developers, I am a Master's student at the ECE department of the University of Florida, USA.​​ For my research project, supervised by Prof. Mark Tehranipoor<http://tehranipoor.ece.ufl.edu/> and Prof. Farimah Farahmandi<http://farimah.ece.ufl.edu/>, I need to use Clang LLVM DataflowSanitizer library in KLEE. However, I have faced some difficulties (explained below) while

Hi Peter, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller is the DataFlowSanitizer, and I don't

On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > Hi Peter, > > > > After discovering several bugs in ArgumentPromotion and > > DeadArgumentElimination where llvm::Functions were replaced with similar > > functions (with the same name) to transform their type

r247321 refactors the code so that it should build on Mac. I haven't actually tested it on Mac -- so please help me and send follow up patches if needed. check-fuzzer will still fail because some of the libFuzzer tests require dfsan. I'd use some help from someone with a Mac to modify lib/Fuzzer/test/CMakeLists.txt so that it does not run dfsan-dependent tests on Mac. Thanks, --kcc On

Kostya, I took a quick stab at patching libFuzzer for Apple, but so far I'm thinking something else is incorrect. Patch is attached but when I went to reproduce the examples, the toy example went fine, but with PCRE and Heartbleed I noticed the coverage statistics were pretty poor, and didn't find anything. Admittedly I moved onto Heartbleed pretty quickly so PCRE probably isn't the

Let in a program a variable 'x' is tainted. There is an assignment 'y=x' where y is untainted. How to check the taintflow in the output or data flow graph ? Any suggestions? Thank you. Have a great day. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190912/5bb3655c/attachment.html>

I'm trying to build the example C++ file on the DFSan sanitizer page: https://clang.llvm.org/docs/DataFlowSanitizer.html However, i'ts complaining about unknown types (intptr_t, uint16_t, uint32_t, uint64_t). I got it to build after adding typedefs from stdint.h and sys/types.h to the sanitizer/common_interface_defs.h header file: typedef __intptr_t intptr_t; typedef u_int16_t uint16_t;