similar to: [LLVMdev] Question about node collapse

Hi John, all, Thanks for your responses everybody. This is actually helpful and I think I now better understand what is going on here. Unless there is a pointer involved, DSA will not collapse nodes. That makes sense... What we would like to leverage DSA for is essentially type-unsafe memory accesses, such as the example where code write a byte into the 0th byte of an integer. Another example

Thanks John! You would not believe this :), but literally just 5 minutes ago I saw the TypeSafety pass and it seems to be exactly what we need. So we'll try to leverage that... Best, -- Zvonimir -- http://zvonimir.info http://soarlab.org/ On Mon, Dec 15, 2014 at 10:28 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 12/14/14, 4:33 PM, Zvonimir Rakamaric wrote: >>

Hi, We just published our work that uses LLVM for software verification: Counterexample-Guided Bit-Precision Selection Shaobo He, Zvonimir Rakamaric Proceedings of the 15th Asian Symposium on Programming Languages and Systems (APLAS), November 2017. Link: http://soarlab.org/2017/09/aplas2017-hr/ I would appreciate if someone could add it to your publication list. Thanks! -- Zvonimir --

Thanks guys! I was looking into ModRef before, but I don't think that's exactly what I need. ModRef API call getModRefInfo requires a Value to be passed to it. However, some memory location M (which is a <DSNode, offset> pair) visible to the caller can be modified in the callee without any Value in the caller actually pointing to that location. I also need to capture those... I

Hello, everyone! I'm writing an automatic memory leak fixing tool recently. For my task, I'm using the DSA (Data Structure Analysis) for alias analysis. In my task, when I detect a memory leak, I need to find a pointer (in C) 'must-alias' with the corresponding resource. In DSA, I think if two Value* point to the same DSNode, they 'may-alias'. If two Value* point to

Any suggestions for how to interpret DSCallGraph's output for the following? I'm trying to use DSCallGraph to get a conservative estimate of a whole-program SCC call graph. I wanted to see how it handles real call-graph cycles involving functions both internal and external to the module. So I made a test program with the following actual call graph, using the standard library's

Thanks for your help John... Yup, I looked at Local.cpp even before I fired off my question to the mailing list. Take a peek here at line 464: https://github.com/llvm-mirror/poolalloc/blob/master/lib/DSA/Local.cpp Based on my understanding of this line, if AtomicCmpXchgInst does not return a pointer type, nothing gets merged. And in the example I posted, a pointer value is indeed not returned

Hi all, I have yet another DSA-related question :), and I would appreciate your help. Actually, the following example generates some interesting potential issues in the LLVM IR too. Here is the example in C: #define CAS(x,y,z) __atomic_compare_exchange_n(x,&(y),z,true,0,0) int main() { int *x = 0; int y = 0; int *z = x; CAS(&z,x,&y); // if (z == x) z = &y; assert(*z ==

Dear Josh, > If I understand correctly, if you find memory leak, you want to find the corresponding call(s) to malloc() that allocated the memory object, correct? Can you more completely explain what you are trying to accomplish? Thanks for your reply. In my task, I use data flow analysis to locate a program point where a malloc must be leaked (by must leaked, I mean (a) it must be

On Thu, Apr 3, 2008 at 4:53 PM, Zvonimir Rakamaric <zrakamar at gmail.com> wrote: > Thanks guys! > > I was looking into ModRef before, but I don't think that's exactly > what I need. ModRef API call getModRefInfo requires a Value to be > passed to it. However, some memory location M (which is a <DSNode, > offset> pair) visible to the caller can be modified

Hi all, I've been using LLVM in my software analysis projects for quite a few years now, and several years back I relied on results of DSA analysis in my SMACK tool for checking C programs. At some point that part of SMACK got deprecated, but now I would like to revisit it since it was working quite well. Therefore, I would like to learn what's the status of the poolalloc project, and

On 12/22/15 4:45 AM, Russell Wallace via llvm-dev wrote: > Oh, I just came across Function::hasAddressTaken. Maybe I can just use > that instead? You could conservatively assume that any function that has its address taken has a pointer to it that escapes into memory or external code. To make things a little more accurate, you could scan the uses of any function for which

John Criswell wrote: > You can sometimes get NULL DSNodes if a previously-run transform pass > adds pointers to the program but doesn't update DSA while claiming to > preserve it. The pool allocation pass, for example, does this: it > claims to preserve the DSA results (when used for SAFECode) but doesn't > properly update the DSGraph when it adds pool handles. Therefore,

Hi, We recently published another paper that leverages LLVM (through our SMACK software verifier and novel tool called Whoop), and this time we focus on detecting concurrency bugs in device drivers: http://soarlab.org/2015/08/ase2015-ddr/ You can find all the required info (PDF, title, abstract, etc.) at the above webpage. I would appreciate if you could add this paper to your list of

Andrew Lenharth wrote: > On Fri, Aug 7, 2009 at 4:45 PM, Patrick Alexander > Simmons<simmon12 at cs.uiuc.edu> wrote: > >> I'm iterating over all LoadInst and StoreInst-type Instructions in a >> Function, and getNodeForValue() is sometimes returning NULL. Why is >> this happening? Shouldn't every load from or store to memory correspond >> to some

On 12/6/12 4:47 PM, Zvonimir Rakamaric wrote: > Hi all, > > I've been using LLVM in my software analysis projects for quite a few > years now, and several years back I relied on results of DSA analysis > in my SMACK tool for checking C programs. > > At some point that part of SMACK got deprecated, but now I would like > to revisit it since it was working quite well.

Dear John, I intend to implement the improvements on DSA. After running DSA on SPEC, I found DSA gives low precision for mcf and bzip2. I have checked the most imprecise c files in mcf an found that the code seems to be a mixture of "PHI" and "GEP" instructions. Could you please give me some hints about what the big picture of the improvement should be and how to start? Thank

Patrick Alexander Simmons wrote: > John Criswell wrote: > >> You can sometimes get NULL DSNodes if a previously-run transform pass >> adds pointers to the program but doesn't update DSA while claiming to >> preserve it. The pool allocation pass, for example, does this: it >> claims to preserve the DSA results (when used for SAFECode) but doesn't >>

Patrick Alexander Simmons wrote: > Andrew Lenharth wrote: > >> On Fri, Aug 7, 2009 at 4:45 PM, Patrick Alexander >> Simmons<simmon12 at cs.uiuc.edu> wrote: >> >> >>> I'm iterating over all LoadInst and StoreInst-type Instructions in a >>> Function, and getNodeForValue() is sometimes returning NULL. Why is >>> this

On 11/29/17 7:42 PM, Zvonimir Rakamaric via llvm-dev wrote: > Counterexample-Guided Bit-Precision Selection I've added this publication to the publication list. Please let me know if I need to make any corrections. Regards, John Criswell -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell