Andrew Pinski wrote:
On Jan 30, 2008 7:59 PM, H.J. Lu <[EMAIL PROTECTED]> 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.
