Re: How to get fndecl on C++ CALL_EXPR?

[Brendon Costa <bcosta at avdat dot com dot au>]

Andrew Pinski wrote:
> On Jan 30, 2008 7:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > I am trying to get fndecl on a C++ CALL_EXPR with get_callee_fndecl.
> > But get_callee_fndecl returns NULL. What is the proper way to
> > get fndecl on a C++ CALL_EXPR in the middle end?
>
> If it is returning NULL, then there is no function decl associated with
> that call, meaning it is an indirect call.  There is nothing you can do then.

If it is an indirect call it is still possible to gather SOME useful 
information (depending on what you are trying to do). I have an 
application (EDoc++) where i find a list of "possible" functions that 
may be executed as the result of an indirect call.

There are two situations i check for:

virtual function calls
function pointer calls

Note: I am not overly familiar with things in GCC. This has worked for 
me so far with GCC 4.0.1.

For virtual functions it seems to be possible to obtain the fndecl for 
the virtual function that is being referenced. This is NOT the actual 
function that is called as that is determined at runtime.

Elsewhere i generate a list of functions that MAY be called as a 
result of a CALL_EXPR to a specific virtual function.


The other case is function pointer calls. In this case i get the type 
of the function pointer being called.

Elsewhere i maintain a list of functions which have had their 
addresses taken and then can match all of these to the function 
pointer type to determine what "MAY" be called.

Obviously there are problems with this approach like you don't get a 
restricted more accurate callgraph but an overly expanded one. It also 
requires data from other translation units, i.e. the fndecl's that MAY 
be called may be in different translation units. However it works fine 
for my purposes.

This was done for a project on sourceforge called EDoc++ that performs 
static analysis of C++ exception propagation.


I do all this in the C++ front end with the GENRIC tree. I am not sure 
if the data i use still exists at the GIMPLE level.

If you are interested in more information on how to do this let me 
know and i will pull out the relevant code. But as Andrew said, 
usually this is only known at runtime and most applications have no 
use knowing this information.

Brendon.