Hello gcc-help list, I am wondering if libgcov is actually thread-safe (reentrant). If I look at this piece of generated code (compilation on PPC architecture via gcc-3.4 -O0 -ftest-coverage -fprofile-args hello.c) lwz r9,0(r11) lwz r10,4(r11) addic r10,r10,1 addze r9,r9 stw r9,0(r11) stw r10,4(r11) it looks to me that there may be race conditions, e.g. that one looses a count when one thread reads in the counter register via lwz and then the other reads in the register via lwz too (leading to a loss of 1 in the count on stw write). In such a situation I am afraid that solve_flow_graph() in gcov.c reconstructing block counts from arc counts may give out coverage>0 for blocks where coverage actually has been 0 (this is the critical case). Q1: Is there an easy way (preferably without much modifications to the compiler) to ensure that the above-mentioned race condition does not happen? (If so, directions would be appreciated.) Q2: If that is not feasible, is it possible to obtain conservative estimates for block coverage (that is to say to ensure that code has been covered at least once) where code reentrance cannot be ruled out? (There is a patch for thread-safe profiling for gcc<=3.3 e.g. http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01543.html but I cannot spot any remains of this in the gcc-3.4+ gcov framework.) Kind regards, -- Holger Blasum, Trainee Engineering, SYSGO AG hbl (a t} sysgo.com -- www.sysgo.com
