similar to: Question about the mailing list.

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;

Hi all, I have some questions about "DataFlowSanitizer" from "compiler-rt". I want to know how I can test the "DataFlowSanitizer"? Can I configure it to label only some values, i.e, the return values from specific functions? Also, how can I print these labels? Thanks, Dareen -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

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

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

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

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

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

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

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>

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 working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

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