indirect calls tracking and control flow graph

Dear all,

I would like to keep track of all the indirect calls that may caused from function

pointers inside a program. I need this in order to be able to construct the control

flow graph of all the indirect calls, that is which function is legal to call another

function.

Is there a module that implements this functionality in llvm? If not, is there a way to
do it? Maybe through implementing a pass. I am new to llvm. Could you suggest me

a way to start doing this? Perhaps the llvm intermediate code can help me on this.

Do you know where this code is being produced? or what files or passes do I have

to modify for this?

Until now I have used this command to produce and study the llvm bitcode for a test
program:
clang -S -emit-llvm fpointers.c -c -o fpointers.bc.text

Thank you,

Hi Thanasis,

You should be able to do this easily by writing a FunctionPass (see
http://llvm.org/docs/WritingAnLLVMPass.html for more info) and
iterating over the instructions in the function, searching for
CallInst instructions and using getCalledFunction() to check if it's
indirect.

Amara

Thank you very much for the information!
I will try it out!

Thanasis

Dear Petsas,

For analyzing indirect function calls, your best bet is probably to use the CallGraph analysis pass that is part of DSA. DSA is included in the poolalloc code; you can get directions on downloading poolalloc from the SVA web page: http://sva.cs.illinois.edu/docs/Install.html.

The release_32 branch works with LLVM 3.2. I think mainline poolalloc was recently updated to work with LLVM 3.4.

Regards,

John Criswell

Thank you! I 'll check this out too.

Hi Thanasis,

You should be able to do this easily by writing a FunctionPass (see
http://llvm.org/docs/WritingAnLLVMPass.html for more info) and
iterating over the instructions in the function, searching for
CallInst instructions and using getCalledFunction() to check if it's
indirect.

This will allow you to determine whether a call is an indirect function call, but it won't give you the targets of the indirect function calls. To get the targets, you need to use a CallGraph analysis (like the one in DSA).

Regards,

John Criswell

Dear Petsas,

For analyzing indirect function calls, your best bet is probably to use
the CallGraph analysis pass that is part of DSA. DSA is included in the
poolalloc code; you can get directions on downloading poolalloc from the
SVA web page: http://sva.cs.illinois.edu/docs/Install.html.

The release_32 branch works with LLVM 3.2. I think mainline poolalloc was
recently updated to work with LLVM 3.4.

Do you know where I can find mainline poolalloc so as I can compile it with
LLVM 3.4 ?

svn co poolalloc Regards, John Criswell

Thank you,

I tried to compile it with llvm 3.4 through these commands:

petsas@shinigami:~/software/poolalloc$ ./configure --with-llvmsrc=/home/petsas/software/llvm --with-llvmobj=/home/petsas/software/llvm

petsas@shinigami:~/software/poolalloc$ make

but I’m getting get this error:

make[1]: Entering directory /home/petsas/software/poolalloc/lib' make[2]: Entering directory /home/petsas/software/poolalloc/lib/DSA’
llvm[2]: Compiling CallTargets.cpp for Debug+Asserts build (PIC)
CallTargets.cpp:35:3: error: use of undeclared identifier ‘DEBUG_TYPE’
STATISTIC (DirCall, “Number of direct calls”);
^
/home/petsas/software/llvm/include/llvm/ADT/Statistic.h:165:38: note: expanded from macro ‘STATISTIC’
static llvm::Statistic VARNAME = { DEBUG_TYPE, DESC, 0, 0 }
^
CallTargets.cpp:36:3: error: use of undeclared identifier ‘DEBUG_TYPE’
STATISTIC (IndCall, “Number of indirect calls”);
^

Any ideas?

Dear Petsas,

I personally haven't used Poolalloc/DSA with anything after LLVM 3.2 or later. Others have applied patches to get it to work with newer versions of LLVM.

That said, after speaking with Will, it looks like poolalloc trunk was patched to work with LLVM trunk. Therefore, my best recommendation is to either:

1) Switch to LLVM trunk and try it with poolalloc trunk. It may or may not work, depending on how much LLVM trunk has changed.

2) Switch to using the release_32 branch of both LLVM and Poolalloc. Unless you need newer LLVM features, I'd go this route as LLVM 3.2 isn't changing anymore. :slight_smile:

-- John T.

Ok, I will switch to release_32. Thank you very much for your help!

Regards,

Thanasis Petsas

Ok, I will switch to release_32. Thank you very much for your help!

Regards,
Thanasis Petsas

Dear Petsas,

I personally haven't used Poolalloc/DSA with anything after LLVM 3.2 or
later. Others have applied patches to get it to work with newer versions
of LLVM.

That said, after speaking with Will, it looks like poolalloc trunk was
patched to work with LLVM trunk. Therefore, my best recommendation is to
either:

1) Switch to LLVM trunk and try it with poolalloc trunk. It may or may
not work, depending on how much LLVM trunk has changed.

Ok, I tested the first option and works fine!