On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> More info on the lto bootstrap failure:
>>
>> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1:
>> warning: Missing counts for called function pex_child_error.isra.1/73
>> [enabled by default]
>> }
>>
>> This is an error handling routine that invokes _exit. Looking at the
>> ipa-profile dump, I can see that all the counts read in for
>> pex_child_error have the value 0. But there is a non-zero callsite,
>> that not surprisingly complains of a profile insanity in the bb's
>> outgoing edge weights, since pex_child_error never returns:
>>
>> ;; basic block 38, loop depth 1, count 192, freq 5000
>> ;; Invalid sum of outgoing counts 0, should be 192
>> ...
>> pex_child_error.isra.1D.5005 (_92, executable_40(D),
>> [/usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c :
>> 677] "execv", _91);
>> ;; succ: 3 [100.0%] (ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
>>
>> Not sure why the counts were all 0 for this routine though, I wouldn't
>> think the early exit should prevent us from updating the counts. But
>> IMO the best thing to do here is to issue a warning, since I don't
>> want more issues like this to cause compile errors when we handled
>> them fine before.
>>
>> Let me know if the patch below is ok.
>
> OK, so _exit actually makes us to miss streaming of the path leading to the
> error message? Handling of vfork is somewhat broken, as I noticed with Martin
> Liska. One problem is that gcov_exit is not clearing the counts. With vfork
> being used in addition to execvs we stream out the data but the counts stays
> in
> the oriignal process memory and then are streamed again. If execve fails and
> leads to _exit I think we can get the miscompare you see.
>
> Does calling gcov_clear within gcov_exit help? (It is what I have in our
> tree)
I thought this was already handled by the __gcov_execv wrapper around
execv which invokes __gcov_flush that in turns does a gcov_exit
followed by gcov_clear?
I think the issue is that we register gcov_exit with atexit(), but
_exit does not execute any atexit functions by definition. So that
would explain why the counters from pex_child_error didn't get dumped.
The caller bb invokes execv before invoking pex_child_error:
execv (executable, to_ptr32 (argv));
pex_child_error (obj, executable, "execv", errno);
So the counters of the caller bb are dumped (hence the caller bb has
non-zero counts) and cleared, and the pex_child_error does not dump
its counters since it uses _exit instead of exit and therefore doesn't
invoke gcov_exit atexit.
If that is what is going on, then I don't see how adding a call to
gcov_clear to gcov_exit would help. Dealing with situations like this
is why I think it is better to convert this to a warning.
Teresa
>
> Honza
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
