This is the mail archive of the
mailing list for the GCC project.
Re: Thread-safety of a profiled binary (and GCOV runtime library)
- From: Nathan Sidwell <nathan at acm dot org>
- To: Martin Liška <mliska at suse dot cz>, 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 08:06:13 -0400
- Subject: Re: Thread-safety of a profiled binary (and GCOV runtime library)
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On 07/25/16 04:14, Martin Liška wrote:
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;
PROF_edge_counter_12 = PROF_edge_counter_11 + 1;
__gcov0._ZL20__gthread_mutex_lockP15pthread_mutex_t = 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, 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.
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
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.
Your phrasing of the problem might be enlightening. 'which is not *properly*
joined'. I.e. don't do that.