similar to: Linker error while linking DataFlowSanitizer to LLVM IR

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:

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

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

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, 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

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 Sat, Mar 31, 2018 at 8:50 AM, 吕涛 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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,

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

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:

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

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

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

Considering F represents the function fputs_unlocked() in an LLVM pass, => F->isVarArg() returns true => F->getNumParams() returns 0 => *F returns declare i32 @fputs_unlocked(...) The signature of fputs_unlocked from man page is: int fputs_unlocked(const char *s, FILE *stream); Can anybody explain why fputs_unlocked() is recognized as a vararg method while it accepts two fixed

You can also `-disable-verify -o <output-filename> ` which will disable the verify check. On Sat, 21 Oct 2017 at 23:54 Dipanjan Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Yes, that definitely works. Wanted to know if there's a switch for file > output or not. > > On 21 October 2017 at 23:45, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: >

Just use Unix IO redirect? `llc -mllvm -print-after-all &> a.txt` 2017-10-22 14:17 GMT+08:00 Dipanjan Das via llvm-dev < llvm-dev at lists.llvm.org>: > > Seems like "-mllvm -print-after-all" does the trick. Is there any switch > that dumps the output to a file instead of console? > > On 21 October 2017 at 21:33, Dipanjan Das <mail.dipanjan.das at

My pass complains and gives up after spitting out: ====================================== Instruction does not dominate all uses! %44 = icmp ne i8** %endptr, null br i1 %44, label %32, label %33 Instruction has bogus parent pointer! ====================================== Is there any way to dump the entire IR even in broken form from the backend so that I can inspect what's going on? --

On 11 June 2017 at 07:53, David Blaikie <dblaikie at gmail.com> wrote: > Sounds like you're looking for reinterpret_cast: http://en. > cppreference.com/w/cpp/language/reinterpret_cast > I tried cast<ConstInt>(vo), but that failed at run-time. > > On Sun, Jun 11, 2017 at 3:06 AM Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

As a concrete question, I understand 'Value' class is the parent of many concrete sub-classes. Let's say I retrieve a Value* value = store_inst->getValueOperand(). Unless I know what the sub-type is, how can I further use this object? I tried something like this: ================================================= Value* value = store_inst->getValueOperand()

I am writing an analysis pass on LLVM which requires to: [1] generate unique, positive ID corresponding to each instruction [2] the ID must survive across runs [3] given the ID, corresponding instruction has to be mapped back For [1], the general suggestion is to use the Value* instr_ptr associated to each instruction. The instr_ptr points to specific instruction in memory, hence