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
>
> 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.
>
>
diff --git a/gcc/common.opt b/gcc/common.opt
index a1544d06824..d382e70317d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2096,6 +2096,10 @@ Common Joined RejectNegative Var(profile_data_prefix)
Set the top-level directory for storing the profile data.
The default is 'pwd'.
+fprofile-note-dir=
+Common Joined RejectNegative Var(profile_note_prefix)
+Set the top-level directory for storing the profile note file.
+
fprofile-correction
Common Report Var(flag_profile_correction)
Enable correction of flow inconsistent profile data input.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 1ffefd5f482..ea7b258d9dd 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1204,6 +1204,12 @@ coverage_init (const char *filename)
int len = strlen (filename);
int prefix_len = 0;
+#if HAVE_DOS_BASED_FILE_SYSTEM
+ const char *separator = "\\";
+#else
+ const char *separator = "/";
+#endif
+
/* Since coverage_init is invoked very early, before the pass
manager, we need to set up the dumping explicitly. This is
similar to the handling in finish_optimization_passes. */
@@ -1217,11 +1223,6 @@ coverage_init (const char *filename)
of filename in order to prevent file path clashing. */
if (profile_data_prefix)
{
-#if HAVE_DOS_BASED_FILE_SYSTEM
- const char *separator = "\\";
-#else
- const char *separator = "/";
-#endif
filename = concat (getpwd (), separator, filename, NULL);
filename = mangle_path (filename);
len = strlen (filename);
@@ -1259,6 +1260,9 @@ coverage_init (const char *filename)
memcpy (bbg_file_name, filename, len);
strcpy (bbg_file_name + len, GCOV_NOTE_SUFFIX);
+ if (profile_note_prefix)
+ bbg_file_name = concat (profile_note_prefix, separator, bbg_file_name, NULL);
+
if (!gcov_open (bbg_file_name, -1))
{
error ("cannot open %s", bbg_file_name);
