similar to: [LLVMdev] DSA / poolalloc: incorrect callgraph for indirect call

John Criswell wrote: > 1) I'll try out your example C++ code below and see if I can get the > same results that you do. However, I'm at a conference right now (Usenix > Security), so I don't know exactly when I'll get to it. Excellent. Thanks, John! > 2) DSA can get pessimistic results when dealing with external code (as > Andrew described). It is designed for

On Wed, Aug 10, 2011 at 1:39 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > The first of those two calls is a vtable dispatch; the ideal answer would be > Base::virt() const and Derived::virt() const, without red() and blue(). >  Still, vtable lookups are complex, so I could imagine an over-approximation > here. > > The second of those two calls is just a non-deterministic

Will Dietz wrote: > This is actually the expected behavior for EQTD :). Expected by you, maybe. :-D > If you switch to TD you'll get better alias-analysis information, and > in this example the correct result. OK, I have switched to TDDataStructures as well, and I am also seeing much better (for my purposes) results in simple tests. I'll keep poking at this some more and

Hi I see when LLVM builds the CallGraph SCCs. a function calling through a function pointer is conservatively assumed to call internal and external functions. Therefore, it has an edges pointing to the externalnode2, ie. the externalnode representing outgoing calls from this module. does LLVM have any function pointer analysis capabilities in the mainline ? Thanks, -Trent

Hello, I have a patch to DSA you may be interested in. I thought I'd post this to llvmdev so it will be archived and googeable in case others need it, even if you decide to not merge this into mainline :-) Here are the highlights: * I refactored StdLibDataStructures::processFunction into processFunction and processCallSite to remove a lot of copy/pasted code. I also moved the libAction

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

John Criswell wrote: > You can use the -debug-pass=Arguments option to opt to print out which > DSA passes it is using. > > -- John T. > The argument list was this: -dsa-local -dsa-stdlib -dsa-bu -dsa-eqtd -poolalloc -preverify -domtree -verify So, the last DSA pass done would appear to have been "-dsa-eqtd". Does this mean pool allocation is using TDeq and not BUeq

I wrote: > I'll keep poking at this some more and let you folks know if I hit any other surprises. Well, that didn't take long. :-) I have found two new surprises in DSCallGraph as built by TDDataStructures. Consider the following program, which is complete and self-contained and which has one simple indirect call site: volatile int unknown; static void red() { } static void

Patrick Alexander Simmons wrote: > Hi, > > I'm trying to run the pool allocation pass through opt, and I'm running > into problems. It segfaults frequently; for example, it does this when > the input is a simple Hello World program: > Can you email me the bitcode file that is causing the problem? > [simmon12 at apoc testcases]$ opt -load >

Hi, I'm trying to run the pool allocation pass through opt, and I'm running into problems. It segfaults frequently; for example, it does this when the input is a simple Hello World program: [simmon12 at apoc testcases]$ opt -load /home/vadve/simmon12/llvm/llvm/projects/llvm-poolalloc/Debug/lib/libLLVMDataStructure.so -load

I hope this is the correct avenue to contact the poolalloc developers. I'm trying to use an alias analysis from the poolalloc repository and can't get it to compile with the latest LLVM. CMake is now required for LLVM, I'm pretty sure at least, but poolalloc does not seem to use it correctly. The README in the project refers to the old Makefiles. I corrected a minor CMake error and a

Kevin Streit wrote: > Hi all, > > is there any plan when poolalloc and DSA will be adapted to compile and run with LLVM 2.7? I'm currently about to start a bigger project using DSA and it would be nice if I could use LLVM 2.7 instead of porting everything I do now from 2.6 to 2.7 later. > Mainline DSA/Poolalloc already compiles with LLVM 2.7. I will probably create a

In an earlier message (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/042298.html), Andrew Lenharth suggested that EQTDDataStructures (from the poolalloc project) may only try to resolve indirect function calls. However, I am now finding that the generated DSCallGraph over-approximates the callees in a very simple indirect call. Some over-approximation is unavoidable, but this case

Hi all, is there any plan when poolalloc and DSA will be adapted to compile and run with LLVM 2.7? I'm currently about to start a bigger project using DSA and it would be nice if I could use LLVM 2.7 instead of porting everything I do now from 2.6 to 2.7 later. Cheers, Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type:

Ryan M. Lefever wrote: > I have a few questions on using dsa now that it has been moved out of > llvm. I have llvm -r release_19 checked out from cvs, and > llvm-poolalloc -r release_19 checked out from cvs into the projects > directory, as John Criswell previously suggested. > > 1) I have some compiler transforms that I'm writing that use DSA. They > can no longer

On Feb 13, 2007, at 11:08 AM, John T. Criswell wrote: > there is a difference between RELEASE_19 and release_19. I have not tried, but I won't be surprised if CVS itself gets confused between this two on systems like Darwin which is case insensitive but case preserving. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have a few questions on using dsa now that it has been moved out of llvm. I have llvm -r release_19 checked out from cvs, and llvm-poolalloc -r release_19 checked out from cvs into the projects directory, as John Criswell previously suggested. 1) I have some compiler transforms that I'm writing that use DSA. They can no longer find the header files for DSA. My transforms are located

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.

I am using EQTDDataStructures (from the poolalloc project) to resolve indirect function calls to over-approximated sets of possible callees. Unfortunately I find that it yields incorrect results even on a very simple test input. My LLVM and poolalloc sources are Subversion trunk checkouts, no more than a day older than the current trunk head. My test input is the following C source,

On Feb 13, 2011, at 12:24 AM, Chris Lattner wrote: > On Feb 2, 2011, at 10:11 AM, Richard Osborne wrote: >> The newlib C library provides iprintf(), a restricted version of printf >> without support for floating-point formatting. I'd like to add an >> optimization which turns calls to printf() into calls to iprintf() if >> the format string has no floating point