Generating a tree of all possible call stacks

Question

I am trying to tinker with some library code written in C++. A fairly complex application sits on top of the library. To tinker with the code, I often need to understand how a library function has been used throughout the codebase, and make sure that I am not breaking any downstream clients.

Suppose foo() is exported from my library's dll. In client code, bar() calls foo(), and baz() calls bar(). I need to make sure that bar and and baz both work after my changes. In my case, the call stack actually is quite deep, and not easy to manually trace because there is not one call stack, there are numerous ways my library function can land at the top of a call stack.

Using either Visual Studio, or g++, or clang, is there a way to generate a tree such that my library function is at the root, and the branches are all the various ways my function can land at the top of the call stack? I mean does such a feature already exist in one of the popular toolchains? If not, do you know any other way of generating such a tree?

Answer 1

I don't think any of the compilers have options to generate this information.

In the general case, there are many confounding factors that would make this very difficult:

• If there's recursion in the code, then the tree you want is actually a graph/network with cycles.

• Virtual methods, function pointers, and member function pointers probably make this the equivalent of the halting problem. If you have two concrete classes A and B that share a common base class that offers virtual method foo(), then you'd have to do exhaustive analysis to determine whether a particular call of foo() through a pointer or reference to the base class should be counted as a call to A::foo() or B::foo() or both. Ditto for the various flavors function pointers.

• If you rely on system or other third-party libraries that can call back into your code, you'd better have source for them. For example, a Windows GUI program typically has window procedures that are called from system code, possibly in response to a call from your code into the system. Since you don't wouldn't have the windows sources, you'd have to assume that any and all of your callbacks could be called at any time, and thus your "tree" would have many roots.

The modern way to deal with this is not to analyze all the ways your library can be called, but to document all the ways it should be called. Build a test suite that calls the library in all the reasonable ways you want to support. Then you can tinker and then run your test suite to see if you've broken the library's contract. If, in integration testing, you find a client of the library that's broken by your changes, it indicates the test suite is incomplete or the client is calling the library in an unsupported way.