search for: showcallgraph

...program, which is complete and self-contained and which has one simple indirect call site: 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 ShowCallGraph testing pass, DSCallGraph lists *zero* callees and claims that its results for the indirect call site are incomplete. Why is it unable to identify the two (seemingly-obvious) callees in this case? The bitcode generated for this call looks like: %7 = phi void (...)* [ bitcast (void ()* @re...

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

...e.g., no variables defined > in other compilation units). Can you: [...] I have made the recommended changes. My test input is now a complete, self-contained program with a proper main. I use "-internalize" on the "opt" command line to run llvm::InternalizePass before my ShowCallGraph pass. (Sadly, llvm::InternalizePass::ID is not exposed through any headers, making it impossible to compile this pass-ordering requirement directly into my ShowCallGraph sources.) The modified test input is attached below. I'm happy to provide compiled bitcode, LLVM assembly source, or w...

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

...ysis getting this wrong? Of course I am trying to build up to more complex, indirect calls. But right now this very simple case has me stuck. Attached below is the complete source code for my pass which prints out the possible callees at each call site. The important logic is at the end, in ShowCallGraph::runOnBasicBlock(). It seems simple enough. Am I doing something wrong here? Thanks, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: ShowCallGraph.cpp Type: text/x-c++src Size: 1404 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-d...

...the other call to be unexpectedly conservative in its over-approximation. Source code for my DSCallGraph tester is attached below. I'd be most grateful for any clues you good people can provide. Thanks, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: ShowCallGraph.cpp Type: text/x-c++src Size: 1379 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110810/6aa969f0/attachment.cpp>

... 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 ShowCallGraph > testing pass, DSCallGraph lists *zero* callees and claims that its results > for the indirect call site are incomplete. Reproduced. > If I save this same program as "test.cpp", compile it with clang, and run my > ShowCallGraph testing pass, DSCallGraph correctly lists both...

... Of course I am trying to build up > to more complex, indirect calls.  But right now this very simple case has me > stuck. > > Attached below is the complete source code for my pass which prints out the > possible callees at each call site.  The important logic is at the end, in > ShowCallGraph::runOnBasicBlock().  It seems simple enough.  Am I doing > something wrong here? > > Thanks, > Ben > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailma...