On Tue, 11 Sep 2018, Martin Liška wrote: > I've discussed the topic with Alexander on the Cauldron and we hoped > that the issue with unique __gcov_root can be handled with DECL_COMMON in > each DSO. > Apparently this approach does not work as all DSOs in an executable have > eventually > just a single instance of the __gcov_root, which is bad.
No, that happens only if they have default visibility. Emitting them with "hidden" visibility solves this. > So that I returned back to catch the root of the failure. It shows that even > with > -Wl,--dynamic-list-data __gcov_indirect_call_callee point to a different > variable > among the DSOs. The reason is that the variable is TLS: (no, that the variable is TLS is not causing the bug; the issue is libraries carry public definitions of just one or both variables depending on if they have indirect calls or not, and the library state becomes "diverged" when one variable gets interposed while the other does not) > That said I would like to go this direction. I would be happy to receive > a feedback. Then I'll test the patch. Hm, this TLS change is attacking the issue from a wrong direction. What I suggested on the Cauldron as a simple and backportable way of solving this is to consolidate the two TLS variables into one TLS struct, which is then either interposed or not as a whole. Alexander
