This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Thread-safety of a profiled binary (and GCOV runtime library)
- From: Martin Liška <mliska at suse dot cz>
- To: Nathan Sidwell <nathan at acm dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, nathan at codesourcery dot com
- Date: Mon, 25 Jul 2016 14:28:06 +0200
- Subject: Re: Thread-safety of a profiled binary (and GCOV runtime library)
- Authentication-results: sourceware.org; auth=none
- References: <a38ae496-1797-2c64-8f2f-93ef831e594e@suse.cz> <e2b89ea8-8998-5966-4030-448c67b9046d@acm.org>
On 07/25/2016 02:06 PM, Nathan Sidwell wrote:
> On 07/25/16 04:14, Martin Liška wrote:
>> Hello.
>>
>> I've just analyzed PR68080, which exposes 2 interesting problems we have:
>>
>> 1) Majority of instrumented profiling code is not thread-safe, for instance edge profiler:
>>
>> PROF_edge_counter_11 = __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0];
>> PROF_edge_counter_12 = PROF_edge_counter_11 + 1;
>> __gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0] = PROF_edge_counter_12;
>>
>> I'm thinking about introducing a param (maybe option), that would instrument counter manipulation
>> in a thread-safe way:
>>
>> __sync_fetch_and_add_8 (&__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t[0], 1);
>
> Agreed. (I'm frankly surprised people have got by without it for so long). Perhaps the existence of an existing threading flag on the command line is sufficient to clue the gcov machinery? I dislike inventing new knobs to twiddle.
I'm also surprised about it :) Let's start without invention of a new flag, I'll work on that.
>
>> 2) The test-case creates a detached thread which is not properly joined. In such situation, the main
>> thread reaches gcov_exit, calculates for instance PROFILE_SUMMARY and serializes counters to a file.
>> However, as the created thread is still running, counters are still updated. The leads to a corrupted
>> profile file.
>>
>> I'm wondering whether to prevent that? I can imagine we can lock the streaming code, where any profile
>> updating thread would not be allowed to do that.
>
> An interesting problem. Conceptually one would want the detatched thread to stop instrumenting -- or instrument to its own set of counters. Neither's really doable within the existing machinery. Grabbing a lock for every counter update is going to be very expensive.
I like the idea sketched by Richard, utilizing TLS and merging counters, which fundamentally the same as merging with existing gcov file.
However, I would put this lower priority than the former problem.
Martin
>
> Your phrasing of the problem might be enlightening. 'which is not *properly* joined'. I.e. don't do that.
>
>
> nathan