Aaron Conole <acon...@bytheb.org> writes: > 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?
Ignore this part, just realized what was going on and it will be correct in the next version. >> nathan
