On Mon, 21 Sep 2020, Martin Liška wrote: > On 9/6/20 1:24 PM, Sergei Trofimovich wrote: > > From: Sergei Trofimovich <siarh...@google.com> > > > > Before the change gcc did not stream correctly TOPN counters > > if counters belonged to a non-local shared object. > > > > As a result zero-section optimization generated TOPN sections > > in a form not recognizable by '__gcov_merge_topn'. > > > > The problem happens because in a case of multiple shared objects > > '__gcov_merge_topn' function is present in address space multiple > > times (once per each object). > > > > The fix is to never rely on function address and predicate on TOPN > > counter types. > > Hello. > > Thank you for the analysis! I think it's the correct fix and it's probably > similar to what we used to see for indirect_call_tuple. > > @Alexander: Am I right?
Yes, analysis presented by Sergei in Bugzilla looks correct. Pedantically I wouldn't say the indirect call issue was similar: it's a different gotcha arising from mixing static and dynamic linking. There we had some symbols preempted by the main executable (but not all symbols), here we have lack of preemption/unification as relevant libgcov symbol is hidden. I cannot judge if the fix is correct (don't know the code that well) but it looks reasonable. If you could come up with a clearer wording for the new comment it would be nice, I struggled to understand it. Thanks. Alexander
