Dell Customer Communication - Confidential > From: Martin Liška <mli...@suse.cz> > Sent: Wednesday, June 19, 2019 3:19 AM > > On 6/18/19 11:51 PM, david.tay...@dell.com wrote: > >> From: Martin Liška <mli...@suse.cz> > >> Sent: Tuesday, June 18, 2019 11:20 AM > >> > >> .gcno files are created during compilation and contain info about a source > file. > >> These files will be created by a cross compiler, so that's fine. > >> > >> During a run of a program a .gcda file is created. It contains > >> information about number of execution of edges. These files are > >> dumped during at_exit by an instrumented application. And the content > >> is stored to a disk (.gcda extension). > >> > >> So what difficulties do you have with that please? > >> > >> Martin > > > > Not sure I understand the question. > > > > Conceptually I don't have any problems with the compiler creating > > .gcno files at compile time and the program creating .gcda files at > > run-time. > > > > As far as the .gcda files go, exit is never called -- it's an embedded > > operating system. The kernel does not call exit. Application > > specific glue code will need to be written. This is to be expected. > > And is completely reasonable. > > Yep, then call __gcov_dump at a place where you want to finish > instrumentation: > https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html > > > > > As far as the .gcno files go -- currently, while doing over 10,000 > > compiles GCC wants to write all the .gcno files to the same file name > > in the same NFS mounted directory. This is simultaneously not useful > > and very very slow. > > Please take a look at attached patch, that will allow you to do: > ./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note-dir=/tmp/ > > $ ls -l /tmp/main.gcno > -rw-r--r-- 1 marxin users 228 Jun 19 09:18 /tmp/main.gcno > > Is the suggested patch working for you? > Martin >
Thanks for the patch. Standalone it is not sufficient. Combined with the other two changes that have been discussed -- . allowing auxbase to be set and . changing the specs to only set auxbase if it isn't already set I think it might well solve the problem. [Although if auxbase is allowed to be set I'm not convinced that this patch is necessary. If auxbase cannot be set, then this patch alone is insufficient.] We do all of our compiles from the top of the workspace. There are a dozen different deliverables being built simultaneously. There are over 3600 *.c files spread across over 200 directories. Each deliverable is built by compiling and linking over 1000 of the *.c files. Overall over 16,000 compiles occur. They are all done from the top directory of the workspace. And each deliverable has its own set of compilation defines. So, foo.o linked into one deliverable may well be different from the foo.o linked into a different one. Further, the build tree structure mimics the source tree structure. So, you might well have two foo.o's in different directories... Our compilation lines combined with the current specs results In GCC trying to create over 16,000 GCNO files all named -.gcno and all living in the top level directory. > > Down the road I'm going to want to make additional changes -- for > > example, putting the instrumentation data into a section specified on > > the command line rather than .data. > > > > Right now I'm concerned about the .gcno files. I want to be able to > > specify the pathname or the base of the pathname on the command line. > > I don't really care whether it is called -auxbase or something else. > > I was thinking '-auxbase' as that is the name currently passed to the > > sub-processes. I do not ultimately care what the name is... > > > > Additionally, if we do this I want it to be done in a manner that when > > contributed back is likely to be accepted. > > > >
