Nathan Sidwell <nat...@acm.org> writes: > On 02/22/16 13:11, Aaron Conole wrote: >> Nathan Sidwell <nat...@acm.org> writes: >> >> Hi Nathan, thanks so much for looking at this! >> >>> On 02/22/16 12:03, Aaron Conole wrote: >>>> The previous gcov behavior was to always output errors on the stderr >>>> channel. >>>> This is fine for most uses, but some programs will require stderr to be >>>> silent for certain tests. This change allows configuring the gcov output by >>>> an environment variable which will be used to open the appropriate file. >>> >>> Why is the invoker unable to direct fd2 before execing gcov? >> >> I want to make sure I understand your question. You are asking why >> something like: ` ./program_executed 2>/path/to/file `` is not preferred? >> >> If this is the question, the problem is program errors will be intermingled >> with gcov error messages. Let's suppose that I've got a unit test >> program (since that's what I have as specifically happening). I expect >> certain tests from that program to spit out errors on stderr. So, I >> filter out that text in stderr, so normal case stderr results will be >> clear. Now, I build with gcov enabled. In this case, gcov writes >> 'profiling:...' to stderr. Now, the test fails, even though nothing >> changed apart from using gcov. > > ah, gotcha! I'd not understood this was in the gcov runtime (as > opposed to the gcov analysis programs).
I'll update $subject to try and make it clearer. Thanks! > Doesn't your use of statics result in multiple fopens in different > shared objects, and subsequent tangling buffering? It would seem to > me that gcov_error_file needs the same linkage as __gcov_master? > Would lazy opening and "w+" be better behaviour? D'oh, you're probably right. In my excitement to contribute, I forgot this was shared. I think 'w' should be correct, since this isn't intended to be read at all, but I could be convinced otherwise. By lazy load, do you mean only after the first gcov_error call? That's probably a better approach, and I can recook, test, and resubmit with these corrected. > BTW, the code formatting needs correcting. Okay. Emacs is autoformatting it to gnu style for me (I thought), is there one I should prefer for gcc contributions? > nathan
