This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] gcov: Runtime configurable destination output
- From: Aaron Conole <aconole at redhat dot com>
- To: Nathan Sidwell <nathan at acm dot org>
- Cc: gcc-patches at gcc dot gnu dot org, Jan Hubicka <hubicka at ucw dot cz>
- Date: Fri, 29 Apr 2016 11:08:04 -0400
- Subject: Re: [PATCH v2] gcov: Runtime configurable destination output
- Authentication-results: sourceware.org; auth=none
- References: <1456350732-8272-1-git-send-email-aconole at bytheb dot org> <f7t60v24vl4 dot fsf at redhat dot com> <59207732-1532-8785-7387-ac793ddad021 at acm dot org>
Nathan Sidwell <nathan@acm.org> writes:
> On 04/27/16 16:59, Aaron Conole wrote:
>> Apologies for the top post. Pinging on this again. It still applies
>> cleanly, so no need to resubmit, I think. Is there anything else missing
>> or required before this can go in?
>
> I'm not convinced this is a desirable feature. IIRC your rationale
> for it was that that you're somehow building the target program with
> inconsistent coverage data, and the messages about that are
> interfering with your program's output.
>
> That's kind of the point of error messages -- to get in your face.
Perhaps I've poorly explained what I want. I want to be able to pipe
gcov error messages to a different file for post-processing / reporting
elsewhere. I don't want them mixed with the application's messages. Do
you think this kind of generic flexibility is not a good thing, when it
comes at such little cost?
The whole point of this is to provide a way to keep the error messages
around. After all, if I really didn't want to see them I could do at
least the following things (untested, just for example):
1. `./myapp 2>/dev/null` (which I don't want to do)
2. { ...; fclose(stderr); stderr = fopen("gcoverrfile", "w"); exit(0); }
3. mkfifo something; ./myapp 2>something; sed -e s,gcov_error_msg,,g something
But, this appeared to me like a generic way of providing what I want
in a way that could apply to any other application, without relying on
workarounds. If that's not a convincing argument, then I guess NAK it
and I'll be done with it - apologies for the noise.
Much thanks for your time,
-Aaron
> nathan