Andrew Pinski wrote:

Why do you need to find (2)?  It is not the function which is actually
called.  DECL_SAVED_TREE might not be set but that is because it has
already been gimplified and lowered to CFG at the time you are looking
through the calls.

Why do you need to know the constructor anyways?

Thanks for the reply.

I am creating a tool that allows users to perform static analysis of C++ exception propogation. Basically while GCC compiles source, I gather certain information that is then embedded as data belonging in a seperate section in the asm file. This then produces an object file in which my data is placed into a seperate section called ".edoc" which allows a post processing tool which extracts this information to construct a complete "pessimistic" call graph of source, and it also gathers other information about exception try/catch blocks and where the function calls are made etc.

I wont go into details about the rest of it because that is not the issue here, but in order to construct a call graph one of the things i need to do is to follow the CALL_EXPR's from say the main() function mentioned in my last email that actuall calls MyClass::__comp_ctor () to the fact that the users defined MyClass::MyClass(MyClass* this) function is being called.

So i need to know that when in the main function for example i come across a CALL_EXPR and the function target for that is a FUNCTION_DECL node for the MyClass::__comp_ctor (MyClass* this), this will actually call: MyClass::MyClass(MyClass* this). This allows me to construct the call graph, otherwise I have a broken link that ends at the __comp_ctor().

Since in the tree there is no implementation for any of the __comp_ctor (), __base_ctor (), ... same for dtor() functions. In my data file i generate a "fake" call graph link which says that the __comp_ctor () calls the MyClass() method.

If there is another way of achiving this I would love to hear it, but I have a mostly working implementation already, this is one of the few problems i have left to iron out.

Thanks,
Brendon.


Reply via email to