similar to: [LLVMdev] EQTDDataStructures omits obvious, direct callee from DSCallGraph

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

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,

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

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

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

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

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

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

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

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

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

I am trying to add a Samba 2.0.7 box to an existing domain. The Samba box will not be a domain controller; it's just going to be a nondescript member of the domain. The primary domain controller is running Windows 2000, but is also configured to emulate an NT4 PDC. Our system administrators did their side of things, and told me that user "domain\liblit" now has permission to add

Dear Prof. Ripley, you mention the theory of perceptrons. Could you please point me to an introduction paper or book? Thanks in previous, Dominik > -----Original Message----- > From: ripley at stats.ox.ac.uk [mailto:ripley at stats.ox.ac.uk] > Sent: dimanche, 10. novembre 2002 18:55 > To: Ben Liblit > Cc: r-help at stat.math.ethz.ch > Subject: Re: [R] building a formula for

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, I would like to propose extending the Control-Flow Integrity (CFI) mechanism in LLVM/Clang with a feature that allows users to explicitly link classes that have no inheritance link. Usually, if one class is used at locations in code where this class is not expected, this will create a CFI error at runtime, assuming the application is built with CFI enabled. However, in cases where the user

Hi Kostya, Please find attached the minimized motivation test. I hope it is minimized enough. If not please let me know so I can try to make it more minimal. Were you expecting something like this? Also I think the tests that I should provide along with the patch should be in a special format right? I think I should be looking at http://llvm.org/docs/DeveloperPolicy.html#test-cases, and

-krasin@ On Fri, Jun 16, 2017 at 11:05 AM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Jun 15, 2017 at 10:39 PM, Enes Göktaş <enes.goktas at gmail.com> > wrote: > >> Hi Kostya, >> >> Please find attached the minimized motivation test. >> I hope it is minimized enough. If not please let me know so I can try to >> make it more

As you noted the class links are actually of the whitelisting kind and not of the blacklisting kind. Doing this with an attribute is pretty interesting and sounds like a better fit to me. I think this could look something like: __attribute__((compatible_vtable_layout("JSComponentMath", "JSComponentImage"))) class ProxyClass{ public: ... } Would this be more admissible? On