This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Introduce libgcov.so run-time library (PR gcov-profile/84107).
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Michael Matz <matz at suse dot de>
- Date: Wed, 12 Sep 2018 16:48:10 +0200
- Subject: Re: [PATCH] Introduce libgcov.so run-time library (PR gcov-profile/84107).
- References: <b8f05b35-ef70-e9c3-b4f9-685fe07e3de0@suse.cz> <CAFiYyc1CpC6DL5FyNSc8knCg-UVz6kHDBSXchxhhmfgHS4rgiA@mail.gmail.com> <7ab7adfb-d2b0-965d-9c5e-f7b6d2c00d67@suse.cz> <CAFiYyc10sNQ-daNgw=je=2RoFr7aLUHXdK8tJLVXrUi5q3PXXg@mail.gmail.com> <41e3cf44-d469-9c87-7042-f79af4a96d4f@suse.cz> <alpine.LNX.2.20.13.1808291852040.10521@monopod.intra.ispras.ru> <e507aac9-22c9-ef0f-38d3-2d8a63022e43@suse.cz> <alpine.LNX.2.20.13.1809111703020.1634@monopod.intra.ispras.ru> <bf071a0d-4a28-baca-8965-8bea6e559647@suse.cz>
On Wed, Sep 12, 2018 at 11:27 AM Martin Liška <mliska@suse.cz> wrote:
>
> On 9/11/18 5:08 PM, Alexander Monakov wrote:
> > 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.
>
> Ah, ok, thanks. So theoretically that way should work.
>
> >
> >> 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)
>
> I see, I'm attaching patch that does that. I can confirm your test-case works
> fine w/o -Wl,--dynamic-list-data.
>
> I'm wondering if it will work as well with dlopen/dlsym machinery? Or now
> the linker flag will be needed?
>
> >
> >> 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.
>
> Got it, current I prefer the solution.
Sounds good. I notice the code had this before but...
+ TREE_PUBLIC (ic_tuple_var) = 1;
+ DECL_EXTERNAL (ic_tuple_var) = 1;
+ TREE_STATIC (ic_tuple_var) = 1;
that's one flag too much?! I suggest to drop DECL_EXTERNAL.
Richard.
> Martin
>
> >
> > Alexander
> >
>