Strange 'function coverage' result in C++ code?

[henry2cox]

I see some strange results that I do not understand.
For example, I have a singleton class "ErrorManager" whose constructor and destructor are defined in file 'errorManger.cpp'
The "function" coverage page for the file contains the following (extracted - many other lines elided):

(note the ErrorManager::~ErrorManager() is hit zero times).

Slightly later on the page, I find:

Note that now we see that "ErrorManager::ErrorManager().2" is hit 2415 times.
(It would be a good guess, to suspect that this regression suite contains 2415 testcases.)

The hrefs for both links point to the same line (.../errorManager.cpp:147) - so it seems clear that these two are aliases for the same function.

Question: why is geninfo (or gcov??) creating these alias entries? Is there a way to stop it?
This is a problem because we tend to care about uncovered code - but quite a few of the "uncovered" functions that we see in the function coverage report are bogus.

I am considering to add a simple filter, to merge the data for all "unique" functions which are declared on the same file/line.
I suspect that the resulting report will be more useful in our current methodology.

[henry2cox]

FWIW: a trivial filter was so easy that I just did it.
The effect was to cut the number of unique functions reported by more than 90% in the project that I used for testing.
(Most of the merged aliases are different template instantiations.)
Update: using the simple hack on a larger, real project cut the number of functions from 260K to about 43K.

[xaizek]

why is geninfo (or gcov??) creating these alias entries?

It's the compiler. There can be different versions of destructors (or functions in general). Some with a call to delete this, some without. I think this happens when the class has a virtual table.

Haven't tried it, but you can try compiling with -ffunction-sections and linking with -Wl,--gc-sections. If those functions are unused, the linker should drop them. In general your filter will produce better results though, because some versions of the same function might be used only partially.

[henry2cox]

Hi – Thanks for the quick response and the explanation. As it turns out, our makefiles already specify ‘-ffunction-sections’ and --gc-sections – so we see the issues with those flags. (I don’t know what we would see if we didn’t use the flags – and I no longer recall why we thought we needed to add them in the first place.) Filtering it is, then (for the moment, at least). It would not be hard to continue to report all the aliases as well (e.g., in an ‘expanded function table’, not unlike the testcase ‘show-details’ table) – but I didn’t implement that because I don’t think any of my users will care. Maybe an even better approach would be to simply merge everything that _doesn’t_ look like a template instantiation difference – and to keep aliases for everything that does. (Again: not done.) Henry

[henry2cox]

Replying to my own issue....
FWIW: I implemented the 'function/alias' table described above (keeping all the aliases). The function coverage detail page now shows each alias groups (in sorted order, always keeping the groups together).

[henry2cox]

#169 is merged - so I'm closing my issue :-)
The workaround is not perfect - but it it good enough.