[llvm-dev] Why getFunction() of CallGraphNode return NULL function?

[Nema, Ashutosh via llvm-dev]

For indirect callSite it’s hard to know the target(or actual) function statically because there can be multiple possibilities.

Regards,
Ashutosh

From: Qiuping Yi [mailto:yiqiuping at gmail.com]
Sent: Wednesday, January 20, 2016 12:03 PM
To: Nema, Ashutosh
Cc: llvm-dev
Subject: Re: [llvm-dev] Why getFunction() of CallGraphNode return NULL function?


So, I won't know the called function statically, Right?


--------------------------------------------
Qiuping Yi
Institute Of Software
Chinese Academy of Sciences

On Wed, Jan 20, 2016 at 2:24 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com<mailto:Ashutosh.Nema at amd.com>> wrote:
Typically for C++ virtual function you will see an indirect callSite (unless not de-virtualized).

Regards,
Ashutosh

From: Qiuping Yi [mailto:yiqiuping at gmail.com<mailto:yiqiuping at gmail.com>]
Sent: Wednesday, January 20, 2016 9:10 AM
To: Nema, Ashutosh
Cc: llvm-dev
Subject: Re: [llvm-dev] Why getFunction() of CallGraphNode return NULL function?

Dear Ashutosh,

Thank you, I can handle some indirect callSites by getFunction() of InvokInst and CallInst.

However, when I am handling C++ programs, I found the calls of member functions are converted
to some strange  indirect calls. For example:

table->truncate(sysTransaction);   // from mysql

are translated to the next complex llvm IR:

_ZN8Database20getSystemTransactionEv.exit:        ; preds = %bb33
  call void @llvm.dbg.value(metadata %class.Transaction.553* %tmp36, i64 0, metadata !7310, metadata !53545), !dbg !69981
  %tmp37 = bitcast %class.Table.543* %table to void (%class.Table.543*, %class.Transaction.553*)***, !dbg !69982
  %tmp38 = load void (%class.Table.543*, %class.Transaction.553*)*** %tmp37, align 8, !dbg !69982, !tbaa !53550
  %tmp39 = getelementptr inbounds void (%class.Table.543*, %class.Transaction.553*)** %tmp38, i64 5, !dbg !69982
  %tmp40 = load void (%class.Table.543*, %class.Transaction.553*)** %tmp39, align 8, !dbg !69982
  invoke void %tmp40(%class.Table.543* %table, %class.Transaction.553* %tmp36)
          to label %bb41 unwind label %bb72, !dbg !69982

and thus I cannot find the called function "truncate" from "invoke void %tmp40(...)", what should I do?
I didn't analysis C++ code with llvm, does all the function calls through objects are translated to such complex indirect calls?
If so, how can I dereference such functions? Thanks!



--------------------------------------------
Qiuping Yi
Institute Of Software
Chinese Academy of Sciences

On Tue, Jan 19, 2016 at 8:23 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com<mailto:Ashutosh.Nema at amd.com>> wrote:
You will see NULL for indirect callSite.
May need to add additional checks for this possibility.

Regards,
Ashutosh

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Qiuping Yi via llvm-dev
Sent: Tuesday, January 19, 2016 5:35 PM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: [llvm-dev] Why getFunction() of CallGraphNode return NULL function?

Hi all,

I want to find all the called functions in each function, thus I iterate the calledFunctions of each CallGraphNode in CallGraph as follow:

for (CallGraph::iterator it = CG->begin(); it != CG->end(); ++it) {
   CallGraphNode* node = it->second;
   for (CallGraphNode::iterator it2 = node->begin(); it2 != node->end(); ++it2) {
      Function* calledFunc = it2->second=>getFunction();
      cerr <<　”function: “ << calledFunc->getName().str() <<"\n";  // crash some times
      ... ...
      ... ...
    }
}

I found that some time "calledFunc" is NULL function and thus the output crash. I don't known why? If the before code is wrong, so what is the correct method for get all the called functions?

I use LLVM 3.6. Thank you all in advance.

--------------------------------------------
Qiuping Yi
Institute Of Software
Chinese Academy of Sciences


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160120/809e6ee5/attachment.html>