Trace large C++ code base?

Question

Problem:

I have just inherited this 200K LOC source code base.

There's only a small part of it I need (and I want to rip all else out).

What I would like to do is to be able to:

1) run the program a few times 2) have something (here's where you come in) record which lines of code gets executed 3) then rip out all the irrelevant lines of code

I realize this has "problems" in the forms of "different args will take different paths"; but for my needs, it's very specific, and I just want something ot get me started on the right line of for ripping stuff out (I'll fine tune those special cases later).

Thanks!

Answer 1

I think the tool gcov might do this for you.

Answer 2

You are probably looking for Code Coverage tools.

This blog post might help: http://www.kimbly.com/blog/000331.html

Answer 3

It would slow your program to a crawl and be a mess to go through, but what about just TRACEing each code line as it's executed?

Or you can do it at the method level, the case level, etc.

Answer 4

You could get that information by profiling. Profilers are usually used for the purpose of determining what's executed most often, but "executed at all" is just a special case. One profiler is gprof.

EDITED to add: gcov, which works via instrumentation and was suggested in other answers, seems to be a much better choice than gprof, which works via sampling.

Answer 5

Just did it with my 1M+ project and recommend using lcov to measure a coverage (it is a set of scripts around gcov which generate html reports), my experience: http://bobah.net/d4d/tools/code-coverage-with-gcov

Answer 6

If you only need a small part of it, it might not be too hard to start with the first file you know will be needed, and try to build it in isolation, along with some unit test code to exercise it. Then add things as they turn out to be necessary - and also refactor where there are unnecessary dependencies. I've done this several times with small pieces of larger codebases, and it's not as bad as you might expect. It also gives me a much better understanding of what I'm reusing and how it works.

Answer 7

Knowing what's executed won't matter if it doesn't even compile so it's pointless to approach it in this manner. If you are certain there's really areas that you don't need just take what you do need (starting with just one file, remove all the includes, and add back until you are able to compile again. Whatever you don't have to include, remove.

Answer 8

You can use various code coverage tools to tell you which parts of the C++ application are executed. One such tool is the SD C++ Test Coverage tool. It produces not only a graphical display of what has been executed (across as many runs/test cases as you care to execute), but also a machine-readable file indicating which lines have been executed, which would be key to ripping out the part not executed.

If you wanted to mechanically rip out the unused code, you'd need a tool that can parse the C++ code, build a represenation of the code, read the "executed line" information and use to that simplify the code to just the test cases you executed, and spit out compilable C++ code at the end. The DMS Software Reengineering Toolkit is capable of carry out massive, reliable transformations on C++ code driven by custom change requirements such as yours.