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); 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 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. Thanks, Martin
