On 09/22/14 08:04, Teresa Johnson wrote:
The approach we now take for LIPO builds is to propagate the counts
LIPO?
for the profiled copy of the COMDAT to other modules. (Additionally the indirect call profiling we perform in LIPO mode would point to a module that we didn't have access to, which is a related issue that the COMDAT fixups we perform at the end of the LIPO profiling run are trying to solve.)
I'm presuming then that all modules of relevance are compiled with coverage information? Propagating counters from one module to another still seems wrong. It'll make it look like the function's executed more times than it really is (per copy). Plus in the general case one can't rely on the copies being identical implementations -- COMDAT only requires they be functionally equivalent.
Correct in that it makes it look like these copies were executed. This was causing some issues when we rewrote/merged profiles with gcov-tool, which essentially operates in whole-program mode. To handle this, this patch marks the modified (previously all-zero) copies in the gcda file. So now gcov-tool can handle them appropriately (clear them on read before doing any analysis), and gcov-dump will flag them.
Um, I don't understand why you're doing this then? If gcov is ignoring the copies, what is the purpose?
nathan
