similar to: Interpreting DSCallGraph results

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,

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

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

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

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

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,

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

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

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

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

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

Hi, I'm trying to write a pass to detect all free()/delete() call instructions in LLVM IR.The method is as follows. First I find Call Instructions: CallInst *CI=dyn_cast<CallInst>(&*i); then see if the Function name matches: name=CI->getCalledFunction()->getName(); if(name=="_ZdlPv"||name=="_ZdaPv"||name=="free")

? Buenas tardes, os pido ayuda sobre el siguiente tema. Tengo interes en mostrar informes con Sweave/Latex y para ello genero tablas con xtable. Sin embargo muestra la tabla al completo cuando lo que deseo es agrupar las celdas con el mismo dato para dar claridad a la tabla. La salida de xtable me genera: [image: Imágenes integradas 3] Para dar claridad lo he intentado con latex(tabular())

I believe the performance of isUnsorted() in sort.c could be improved by calling REAL() once (outside of the for loop), rather than calling it twice inside the loop. As an aside, it is implemented in the faster way in doSort() (sort.c line 401). The example below shows the performance improvement for a vectors of double of moving REAL() outside the for loop. # example as implemented in

Hi all I just saw that I miss some log files in /var/log/httpd. There is a gap in January/February2016, no logs are available for this period. It seemed to work fine with the earlier logs as you can see. Has someone an explanation for this? It's a Centos 7.2 VM with Apache 2.4 running ownCloud only. Default logrotate config. -rw-r--r-- 1 root root 3367604 Apr 20 16:12 ssl_access_log