This is the mail archive of the
mailing list for the GCC project.
Thread-safety of a profiled binary (and GCOV runtime library)
- From: Martin Liška <mliska at suse dot cz>
- To: 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 10:14:50 +0200
- Subject: Thread-safety of a profiled binary (and GCOV runtime library)
- Authentication-results: sourceware.org; auth=none
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);
That would also require very similar support for gcov run-time library.
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.