A tool for determining which functions may ultimately cause a call (list) of low-level functions

Question

I have a very large C ++ program where some low-level functions should only be called from certain contexts or when taking specific precautions. I am looking for a tool that shows me which of these low-level functions call higher-level functions. I would prefer it to be visible in an IDE with a drop-down or labeled label, possibly in an annotated source release, but any simpler method than manual search for the call graph will help.

This is a static analysis problem, and the profiler does not help me.

Mostly I work on mac, linux is fine, and if something is only available for windows, I can live with it.

Update

Simply, when the call graph does not speed up the answer to the question, "does foo () potentially make the call x () y () or z ()". (or am I missing something in call-graph tools, maybe I need to write a program that crosses it to get a solution?)

Answer 1

There is a Clang Static Analyzer that uses LLVM, which should also be present in OS X. In fact, I believe this is integrated into Xcode. Anyway, there is a GUI.

In addition, there are several LLVM passes where you can generate call schedules, but I'm not sure if this is what you want.

Answer 2

The Scientific Understanding Tool should be able to create call graphs for C and C ++.

Doxygen also allegedly creates call schedules.

I have no experience with any of them, but with some harsh opinions. You should keep in mind that I am a supplier of another tool, so take this opinion with lots of salt.

I have experience building fairly accurate call schedules for massive C systems (25 million lines) with 250,000 functions.

One problem that I encounter when building a realistic call schedule is indirect function calls, and for C ++, overloaded method function calls. In large systems, there are many. To determine what is called when calling FOO, your tool must have a deep semantic understanding of how the compiler / language resolves an overloaded call, and also for indirect function calls - a fairly accurate definition of what a function pointer can actually point to in a large system. If you do not get these reasonable rights, your call schedule will contain many false positives (for example, fictitious claims A calls B), and on the scale of false positives - a disaster.

For C ++, you should have what constitutes the complete end of the compiler. Neither Understand nor Doxygen have this, so I don’t see how they can really understand the C ++ / Koenig overload rules. Neither understand nor Doxygen do the attempts that I know to reason about indirect function calls.

Our DMS Software Reengineering Toolkit really makes call schedules for C pretty good, even with indirect function pointers, using the exact front end of the C language .

We have a C ++ language with a clear interface , and it correctly allows overloading (to the extent that the C ++ committee agrees with this, and we understand what they said and what individual compilers do [they do not always agree] ), and we have something like Doxygen that shows this information. Currently, we do not have an analysis of function pointers for C ++, but we are working on it (we have complete diagrams of the control flow inside the methods and a big step).

I understand CLANG has some option for calculating call schedules, and I expect this to be accurate when overloaded, since Clang is essentially a C ++ compiler implemented with a set of components. I don't know what if Klang does something to parse function pointers.