https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118553
--- Comment #5 from Roland Illig <roland.illig at gmx dot de> --- (In reply to Jan Hubicka from comment #4) > > There is a __gcov_fork but none for vfork > Hmm, with vfork the address space is shared, so updated from child > process should be visible to the outer process? On NetBSD with GCC 10.5.0, the execution trace is: 9017 9017 sh CALL execve(0xc4c2d8,0xc4c2f0,0xc4c300) 9017 9017 prog RET execve JUSTRETURN 6990 6990 prog NAMI ".../tests/usr.bin/gcov/prog.gcda" 6990 6990 prog CALL execve(0x404008,0x7f7fff861210,0x7f7fff8613a8) 6990 6990 sh RET execve JUSTRETURN 9017 9017 prog NAMI ".../tests/usr.bin/gcov/prog.gcda" That is, first the child process 6990 syncs with the .gcda file, and later, the parent process 9017 syncs with the .gcda file. On NetBSD with GCC 12.4.0, the execution trace is: 17039 17039 sh CALL execve(0x3f32d8,0x3f32f0,0x3f3300) 17039 17039 prog RET execve JUSTRETURN 9625 9625 prog NAMI ".../tests/usr.bin/gcov/prog.gcda" 9625 9625 prog CALL execve(0x404008,0x7f7ffff2b900,0x7f7ffff2ba98) 9625 9625 sh RET execve JUSTRETURN 9777 9777 sh CALL execve(0x3f3428,0x3f3338,0x3f3350) That is, the child process 9625 syncs with the .gcda file, but the parent process 17039 just exits, without syncing the file. >From this observation, my guess is that there is a flag "gcda file already synced" that gets updated by the vfork/execl calls but not by the fork/execl calls. This would explain the output I saw. Is there such a flag in gcov?
