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.
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.
Your phrasing of the problem might be enlightening. 'which is not *properly*
joined'. I.e. don't do that.
nathan
