similar to: [LLVMdev] incorrect DSCallGraph for simple indirect call with vtable nearby

Dear Ben, Just a few comments on DSA: 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. 2) DSA can get pessimistic results when dealing with external code (as Andrew described). It is designed for whole program analysis, meaning

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

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

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 Thu, Aug 11, 2011 at 11:10 AM, Ben Liblit <liblit at cs.wisc.edu> wrote: >        volatile int unknown; > >        static void red() { } >        static void blue() { } > >        int main() >        { >          (unknown ? red : blue)(); >          return 0; >        } > > If I save this as "test.c", compile it with clang, and run my

On Wed, Aug 10, 2011 at 10:37 AM, Ben Liblit <liblit at cs.wisc.edu> wrote: > Equally strange: if I comment out the "base->virt();" call, then DSCallGraph > *does* give the expected answer that "(unknown ? red : blue)()" could call > either red() or blue() but not Base::virt(). Somehow having that > vtable-based call present forces the other call to be

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

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,

Andrew Lenharth wrote: > If I remember correctly, it only tries to resolve indirect calls. The > analysis doesn't track direct calls because you can do it just as well > yourself. DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to iterate over an empty set (EmptyActual) for any call site not found in the ActualCallees map. So if direct calls are not tracked,

Hi, Ben, As Will suggested, try the TD pass, not EQTD, and see if that works better for you. Having said that, DSA currently doesn't do well with vtables. It is not a fundamental limitation of the algorithm itself and we think we know how to improve it, so if those are important to you, let me know. DSA is indeed a unification-style analysis, not inclusion based. It is partially context

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

On Tue, Aug 9, 2011 at 10:45 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > Andrew Lenharth wrote: >> If I remember correctly, it only tries to resolve indirect calls.  The >> analysis doesn't track direct calls because you can do it just as well >> yourself. > > DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to > iterate over an empty

On Tue, Aug 9, 2011 at 6:19 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > I am using EQTDDataStructures (from the poolalloc project) to resolve > indirect function calls to over-approximated sets of possible callees. If I remember correctly, it only tries to resolve indirect calls. The analysis doesn't track direct calls because you can do it just as well yourself. Andrew

> On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote: >>> [snip] >>> -- John T. >> Sorry, I am asking the second question. >> " >> how to determine, within an LLVM pass, what the >> possible target(s) of an indirect function call might be? > > There are at least two solutions. > > The first is to use the CallGraph analysis pass. It

On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote: >> [snip] >> -- John T. > Sorry, I am asking the second question. > " > how to determine, within an LLVM pass, what the > possible target(s) of an indirect function call might be? There are at least two solutions. The first is to use the CallGraph analysis pass. It constructs a conservative call graph, meaning that

> On 1/26/11 3:00 PM, songlh at cs.wisc.edu wrote: >>> On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote: >>>> thanks! >>>> >>>> After I check the ll file, I find this: >>>> >>>> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048 >>>> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg

Hello, I am trying to apply DSA (from the poolalloc project - I'm on LLVM 3.2) on the following C program and found that the generated callgraph over-approximates the callees for the simple indirect call. #include <stdio.h> __attribute__((noinline)) static int f1(int arg1, int arg2) { return arg1 + arg2; } __attribute__((noinline)) static int run_func(int (*fptr)(int, int), int

Hi, Can someone help me with how to dump the vtable and the vptr addresses within it? Thanks, Dami -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170529/5dc7e058/attachment.html>

hi my reports are not well displayed on my access97 app. fonts are displayed i anora location and separed I got this fixme fixme:font:load_VDMX Failed to retrieve vTable somebdoy knows how to fix it? thanks all

Dear Mailing List, This might sound unconventional, but I am trying to access a C++ objects vtable to pass as an argument to a function call for a library function I created. Creating & inserting a function call at the correct location in LLVM is done. I have learned that C++ objects are represented as struct types. But I'm just not quite sure how to get at the vtable pointer within,