Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
On 07/20/2018 06:02 AM, Bin.Cheng wrote: > On Fri, Jun 29, 2018 at 9:54 PM, Martin Liška wrote: >> On 06/22/2018 10:35 PM, Jeff Law wrote: >>> On 05/16/2018 05:53 AM, Martin Liška wrote: >>>> On 12/21/2017 10:13 AM, Martin Liška wrote: >>>>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >>>>>> Another thing is that the "/" in there is wrong, so >>>>>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >>>>>> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >>>>>> needs to be used instead. >>>>> This looks much nicer, I forgot about DIR_SEPARATOR. >>>>> >>>>>> Does profile_data_prefix have any dir separators stripped from the end? >>>>> That's easy to achieve.. >>>>> >>>>>> Is pwd guaranteed to be relative in this case? >>>>> .. however this is absolute path, which would be problematic on a DOC >>>>> based FS. >>>>> Maybe we should do the same path mangling as we do for purpose of gcov: >>>>> >>>>> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 >>>> Hi. >>>> >>>> I decided to implement that. Which means for: >>>> >>>> $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out >>>> >>>> we get following file: >>>> /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda >>>> >>>> That guarantees we have a unique file path. As seen in the PR it >>>> can produce a funny ICE. >>>> >>>> I've been testing the patch. >>>> Ready after it finishes tests? >>>> >>>> Martin >>>> >>>>> What do you think about it? >>>>> Regarding the string manipulation: I'm not an expert, but work with >>>>> string in C >>>>> is for me always a pain :) >>>>> >>>>> Martin >>>>> >>>> >>>> 0001-When-using-fprofile-generate-some-path-mangle-absolu.patch >>>> >>>> >>>> From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 >>>> From: marxin >>>> Date: Wed, 16 Aug 2017 10:22:57 +0200 >>>> Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute >>>> path >>>> of file (PR lto/85759). >>>> >>>> gcc/ChangeLog: >>>> >>>> 2018-05-16 Martin Liska >>>> >>>> PR lto/85759 >>>> * coverage.c (coverage_init): Mangle full path name. >>>> * doc/invoke.texi: Document the change. >>>> * gcov-io.c (mangle_path): New. >>>> * gcov-io.h (mangle_path): Likewise. >>>> * gcov.c (mangle_name): Use mangle_path for path mangling. >>> ISTM you can self-approve this now if you want it to move forward :-) >>> >>> jeff >>> >> >> Sure, let me install the patch then. > Hi, > I am a bit confused after path mangling change. > Now with below command line: Hi. > $ ./gcc -O2 -fprofile-use=./ sort.c -o sort.c Does not make sense, it's default. When using argument to the option, an absolute path is preferred to be used. > or > $ ./gcc -O2 -fprofile-use=./sort.gcda sort.c -o sort.c Should be always a folder, not a path to a file. > > The da_file_name and the final name used in gcov_open is as: > > $ p name > $11 = 0x2e63050 > ./#home#chengbin.cb#work#gcc-patches#trunk-orig#target.build#bin#sort.gcda > or > p da_file_name > $1 = 0x2e63050 > "sort.gcda/#home#chengbin.cb#work#gcc-patches#trunk-orig#target.build#bin#sort.gcda" > > > These are not valid paths? Or how should I modify the command line options? Yes, please fix options. Martin > > Thanks, > bin >> >> Martin
Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
On Fri, Jun 29, 2018 at 9:54 PM, Martin Liška wrote: > On 06/22/2018 10:35 PM, Jeff Law wrote: >> On 05/16/2018 05:53 AM, Martin Liška wrote: >>> On 12/21/2017 10:13 AM, Martin Liška wrote: >>>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >>>>> Another thing is that the "/" in there is wrong, so >>>>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >>>>> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >>>>> needs to be used instead. >>>> This looks much nicer, I forgot about DIR_SEPARATOR. >>>> >>>>> Does profile_data_prefix have any dir separators stripped from the end? >>>> That's easy to achieve.. >>>> >>>>> Is pwd guaranteed to be relative in this case? >>>> .. however this is absolute path, which would be problematic on a DOC >>>> based FS. >>>> Maybe we should do the same path mangling as we do for purpose of gcov: >>>> >>>> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 >>> Hi. >>> >>> I decided to implement that. Which means for: >>> >>> $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out >>> >>> we get following file: >>> /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda >>> >>> That guarantees we have a unique file path. As seen in the PR it >>> can produce a funny ICE. >>> >>> I've been testing the patch. >>> Ready after it finishes tests? >>> >>> Martin >>> >>>> What do you think about it? >>>> Regarding the string manipulation: I'm not an expert, but work with string >>>> in C >>>> is for me always a pain :) >>>> >>>> Martin >>>> >>> >>> 0001-When-using-fprofile-generate-some-path-mangle-absolu.patch >>> >>> >>> From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 >>> From: marxin >>> Date: Wed, 16 Aug 2017 10:22:57 +0200 >>> Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute >>> path >>> of file (PR lto/85759). >>> >>> gcc/ChangeLog: >>> >>> 2018-05-16 Martin Liska >>> >>> PR lto/85759 >>> * coverage.c (coverage_init): Mangle full path name. >>> * doc/invoke.texi: Document the change. >>> * gcov-io.c (mangle_path): New. >>> * gcov-io.h (mangle_path): Likewise. >>> * gcov.c (mangle_name): Use mangle_path for path mangling. >> ISTM you can self-approve this now if you want it to move forward :-) >> >> jeff >> > > Sure, let me install the patch then. Hi, I am a bit confused after path mangling change. Now with below command line: $ ./gcc -O2 -fprofile-use=./ sort.c -o sort.c or $ ./gcc -O2 -fprofile-use=./sort.gcda sort.c -o sort.c The da_file_name and the final name used in gcov_open is as: $ p name $11 = 0x2e63050 ./#home#chengbin.cb#work#gcc-patches#trunk-orig#target.build#bin#sort.gcda or p da_file_name $1 = 0x2e63050 "sort.gcda/#home#chengbin.cb#work#gcc-patches#trunk-orig#target.build#bin#sort.gcda" These are not valid paths? Or how should I modify the command line options? Thanks, bin > > Martin
Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
On 16/05/18 13:53 +0200, Martin Liška wrote: On 12/21/2017 10:13 AM, Martin Liška wrote: On 12/20/2017 06:45 PM, Jakub Jelinek wrote: Another thing is that the "/" in there is wrong, so const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); needs to be used instead. This looks much nicer, I forgot about DIR_SEPARATOR. Does profile_data_prefix have any dir separators stripped from the end? That's easy to achieve.. Is pwd guaranteed to be relative in this case? .. however this is absolute path, which would be problematic on a DOC based FS. Maybe we should do the same path mangling as we do for purpose of gcov: https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 Hi. I decided to implement that. Which means for: $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out we get following file: /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda That guarantees we have a unique file path. As seen in the PR it can produce a funny ICE. I've been testing the patch. Ready after it finishes tests? Martin What do you think about it? Regarding the string manipulation: I'm not an expert, but work with string in C is for me always a pain :) Martin From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 16 Aug 2017 10:22:57 +0200 Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759). gcc/ChangeLog: 2018-05-16 Martin Liska PR lto/85759 * coverage.c (coverage_init): Mangle full path name. * doc/invoke.texi: Document the change. * gcov-io.c (mangle_path): New. * gcov-io.h (mangle_path): Likewise. * gcov.c (mangle_name): Use mangle_path for path mangling. --- gcc/coverage.c | 20 ++-- gcc/doc/invoke.texi | 3 +++ gcc/gcov-io.c | 49 + gcc/gcov-io.h | 1 + gcc/gcov.c | 37 + 5 files changed, 72 insertions(+), 38 deletions(-) diff --git a/gcc/coverage.c b/gcc/coverage.c index 32ef298a11f..6e621c3ff96 100644 --- a/gcc/coverage.c +++ b/gcc/coverage.c @@ -1227,8 +1227,24 @@ coverage_init (const char *filename) g->get_passes ()->get_pass_profile ()->static_pass_number; g->get_dumps ()->dump_start (profile_pass_num, NULL); - if (!profile_data_prefix && !IS_ABSOLUTE_PATH (filename)) -profile_data_prefix = getpwd (); + if (!IS_ABSOLUTE_PATH (filename)) +{ + /* When a profile_data_prefix is provided, then mangle full path +of filename in order to prevent file path clashing. */ + if (profile_data_prefix) + { +#if HAVE_DOS_BASED_FILE_SYSTEM + const char separator = "\\"; As mentioned on IRC, this is ill-formed due to the missing * +#else + const char *separator = "/"; +#endif + filename = concat (getpwd (), separator, filename, NULL); + filename = mangle_path (filename); + len = strlen (filename); + } + else + profile_data_prefix = getpwd (); +} if (profile_data_prefix) prefix_len = strlen (profile_data_prefix); diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index ca3772bbebf..4859cec0ab5 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -11253,6 +11253,9 @@ and used by @option{-fprofile-use} and @option{-fbranch-probabilities} and its related options. Both absolute and relative paths can be used. By default, GCC uses the current directory as @var{path}, thus the profile data file appears in the same directory as the object file. +In order to prevent filename clashing, if object file name is not an absolute +path, we mangle absolute path of @file{@var{sourcename}.gcda} file and +use it as file name of a @file{.gcda} file. This is missing several definite articles, and is inconsistent about using "filename" and "file name", i.e. In order to prevent the file name clashing, if the object file name is not an absolute path, we mangle the absolute path of the @file{@var{sourcename}.gcda} file and use it as the file name of a @file{.gcda} file.
Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
Hi Martin, > On 06/22/2018 10:35 PM, Jeff Law wrote: >> On 05/16/2018 05:53 AM, Martin Liška wrote: >>> On 12/21/2017 10:13 AM, Martin Liška wrote: >>>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >>>>> Another thing is that the "/" in there is wrong, so >>>>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >>>>> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >>>>> needs to be used instead. >>>> This looks much nicer, I forgot about DIR_SEPARATOR. >>>> >>>>> Does profile_data_prefix have any dir separators stripped from the end? >>>> That's easy to achieve.. >>>> >>>>> Is pwd guaranteed to be relative in this case? >>>> .. however this is absolute path, which would be problematic on a DOC >>>> based FS. >>>> Maybe we should do the same path mangling as we do for purpose of gcov: >>>> >>>> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 >>> Hi. >>> >>> I decided to implement that. Which means for: >>> >>> $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out >>> >>> we get following file: >>> /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda >>> >>> That guarantees we have a unique file path. As seen in the PR it >>> can produce a funny ICE. >>> >>> I've been testing the patch. >>> Ready after it finishes tests? >>> >>> Martin >>> >>>> What do you think about it? >>>> Regarding the string manipulation: I'm not an expert, but work with >>>> string in C >>>> is for me always a pain :) >>>> >>>> Martin >>>> >>> >>> 0001-When-using-fprofile-generate-some-path-mangle-absolu.patch >>> >>> >>> From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 >>> From: marxin >>> Date: Wed, 16 Aug 2017 10:22:57 +0200 >>> Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute >>> path >>> of file (PR lto/85759). >>> >>> gcc/ChangeLog: >>> >>> 2018-05-16 Martin Liska >>> >>> PR lto/85759 >>> * coverage.c (coverage_init): Mangle full path name. >>> * doc/invoke.texi: Document the change. >>> * gcov-io.c (mangle_path): New. >>> * gcov-io.h (mangle_path): Likewise. >>> * gcov.c (mangle_name): Use mangle_path for path mangling. >> ISTM you can self-approve this now if you want it to move forward :-) >> >> jeff >> > > Sure, let me install the patch then. your patch caused 3 testcases to regress everywhere: +UNRESOLVED: gcc.dg/pr47793.c scan-file . +FAIL: gcc.dg/profile-dir-1.c scan-ipa-dump cgraph " ./profile-dir-1.gcda" +FAIL: gcc.dg/profile-dir-3.c scan-ipa-dump cgraph " ./profile-dir-3.gcda" Please fix. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
On 06/22/2018 10:35 PM, Jeff Law wrote: > On 05/16/2018 05:53 AM, Martin Liška wrote: >> On 12/21/2017 10:13 AM, Martin Liška wrote: >>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >>>> Another thing is that the "/" in there is wrong, so >>>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >>>> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >>>> needs to be used instead. >>> This looks much nicer, I forgot about DIR_SEPARATOR. >>> >>>> Does profile_data_prefix have any dir separators stripped from the end? >>> That's easy to achieve.. >>> >>>> Is pwd guaranteed to be relative in this case? >>> .. however this is absolute path, which would be problematic on a DOC based >>> FS. >>> Maybe we should do the same path mangling as we do for purpose of gcov: >>> >>> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 >> Hi. >> >> I decided to implement that. Which means for: >> >> $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out >> >> we get following file: >> /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda >> >> That guarantees we have a unique file path. As seen in the PR it >> can produce a funny ICE. >> >> I've been testing the patch. >> Ready after it finishes tests? >> >> Martin >> >>> What do you think about it? >>> Regarding the string manipulation: I'm not an expert, but work with string >>> in C >>> is for me always a pain :) >>> >>> Martin >>> >> >> 0001-When-using-fprofile-generate-some-path-mangle-absolu.patch >> >> >> From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 >> From: marxin >> Date: Wed, 16 Aug 2017 10:22:57 +0200 >> Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute >> path >> of file (PR lto/85759). >> >> gcc/ChangeLog: >> >> 2018-05-16 Martin Liska >> >> PR lto/85759 >> * coverage.c (coverage_init): Mangle full path name. >> * doc/invoke.texi: Document the change. >> * gcov-io.c (mangle_path): New. >> * gcov-io.h (mangle_path): Likewise. >> * gcov.c (mangle_name): Use mangle_path for path mangling. > ISTM you can self-approve this now if you want it to move forward :-) > > jeff > Sure, let me install the patch then. Martin
Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
On 05/16/2018 05:53 AM, Martin Liška wrote: > On 12/21/2017 10:13 AM, Martin Liška wrote: >> On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >>> Another thing is that the "/" in there is wrong, so >>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >>> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >>> needs to be used instead. >> This looks much nicer, I forgot about DIR_SEPARATOR. >> >>> Does profile_data_prefix have any dir separators stripped from the end? >> That's easy to achieve.. >> >>> Is pwd guaranteed to be relative in this case? >> .. however this is absolute path, which would be problematic on a DOC based >> FS. >> Maybe we should do the same path mangling as we do for purpose of gcov: >> >> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 > Hi. > > I decided to implement that. Which means for: > > $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out > > we get following file: > /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda > > That guarantees we have a unique file path. As seen in the PR it > can produce a funny ICE. > > I've been testing the patch. > Ready after it finishes tests? > > Martin > >> What do you think about it? >> Regarding the string manipulation: I'm not an expert, but work with string >> in C >> is for me always a pain :) >> >> Martin >> > > 0001-When-using-fprofile-generate-some-path-mangle-absolu.patch > > > From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 > From: marxin > Date: Wed, 16 Aug 2017 10:22:57 +0200 > Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute path > of file (PR lto/85759). > > gcc/ChangeLog: > > 2018-05-16 Martin Liska > > PR lto/85759 > * coverage.c (coverage_init): Mangle full path name. > * doc/invoke.texi: Document the change. > * gcov-io.c (mangle_path): New. > * gcov-io.h (mangle_path): Likewise. > * gcov.c (mangle_name): Use mangle_path for path mangling. ISTM you can self-approve this now if you want it to move forward :-) jeff
Re: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
PING^1 On 05/16/2018 01:53 PM, Martin Liška wrote: > On 12/21/2017 10:13 AM, Martin Liška wrote: >> On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >>> Another thing is that the "/" in there is wrong, so >>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >>> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >>> needs to be used instead. >> >> This looks much nicer, I forgot about DIR_SEPARATOR. >> >>> Does profile_data_prefix have any dir separators stripped from the end? >> >> That's easy to achieve.. >> >>> Is pwd guaranteed to be relative in this case? >> >> .. however this is absolute path, which would be problematic on a DOC based >> FS. >> Maybe we should do the same path mangling as we do for purpose of gcov: >> >> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 > > Hi. > > I decided to implement that. Which means for: > > $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out > > we get following file: > /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda > > That guarantees we have a unique file path. As seen in the PR it > can produce a funny ICE. > > I've been testing the patch. > Ready after it finishes tests? > > Martin > >> >> What do you think about it? >> Regarding the string manipulation: I'm not an expert, but work with string >> in C >> is for me always a pain :) >> >> Martin >> >
[PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759).
On 12/21/2017 10:13 AM, Martin Liška wrote: > On 12/20/2017 06:45 PM, Jakub Jelinek wrote: >> Another thing is that the "/" in there is wrong, so >> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' }; >> char *b = concat (profile_data_prefix, dir_separator_str, pwd, NULL); >> needs to be used instead. > > This looks much nicer, I forgot about DIR_SEPARATOR. > >> Does profile_data_prefix have any dir separators stripped from the end? > > That's easy to achieve.. > >> Is pwd guaranteed to be relative in this case? > > .. however this is absolute path, which would be problematic on a DOC based > FS. > Maybe we should do the same path mangling as we do for purpose of gcov: > > https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L2424 Hi. I decided to implement that. Which means for: $ gcc -fprofile-generate=/tmp/myfolder empty.c -O2 && ./a.out we get following file: /tmp/myfolder/#home#marxin#Programming#testcases#tmp#empty.gcda That guarantees we have a unique file path. As seen in the PR it can produce a funny ICE. I've been testing the patch. Ready after it finishes tests? Martin > > What do you think about it? > Regarding the string manipulation: I'm not an expert, but work with string in > C > is for me always a pain :) > > Martin > >From 386a4561a4d1501e8959871791289e95f6a89af5 Mon Sep 17 00:00:00 2001 From: marxin <mli...@suse.cz> Date: Wed, 16 Aug 2017 10:22:57 +0200 Subject: [PATCH] When using -fprofile-generate=/some/path mangle absolute path of file (PR lto/85759). gcc/ChangeLog: 2018-05-16 Martin Liska <mli...@suse.cz> PR lto/85759 * coverage.c (coverage_init): Mangle full path name. * doc/invoke.texi: Document the change. * gcov-io.c (mangle_path): New. * gcov-io.h (mangle_path): Likewise. * gcov.c (mangle_name): Use mangle_path for path mangling. --- gcc/coverage.c | 20 ++-- gcc/doc/invoke.texi | 3 +++ gcc/gcov-io.c | 49 + gcc/gcov-io.h | 1 + gcc/gcov.c | 37 + 5 files changed, 72 insertions(+), 38 deletions(-) diff --git a/gcc/coverage.c b/gcc/coverage.c index 32ef298a11f..6e621c3ff96 100644 --- a/gcc/coverage.c +++ b/gcc/coverage.c @@ -1227,8 +1227,24 @@ coverage_init (const char *filename) g->get_passes ()->get_pass_profile ()->static_pass_number; g->get_dumps ()->dump_start (profile_pass_num, NULL); - if (!profile_data_prefix && !IS_ABSOLUTE_PATH (filename)) -profile_data_prefix = getpwd (); + if (!IS_ABSOLUTE_PATH (filename)) +{ + /* When a profile_data_prefix is provided, then mangle full path + 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); + } + else + profile_data_prefix = getpwd (); +} if (profile_data_prefix) prefix_len = strlen (profile_data_prefix); diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index ca3772bbebf..4859cec0ab5 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -11253,6 +11253,9 @@ and used by @option{-fprofile-use} and @option{-fbranch-probabilities} and its related options. Both absolute and relative paths can be used. By default, GCC uses the current directory as @var{path}, thus the profile data file appears in the same directory as the object file. +In order to prevent filename clashing, if object file name is not an absolute +path, we mangle absolute path of @file{@var{sourcename}.gcda} file and +use it as file name of a @file{.gcda} file. @item -fprofile-generate @itemx -fprofile-generate=@var{path} diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c index 3fe1e613ebc..68660d6d3cf 100644 --- a/gcc/gcov-io.c +++ b/gcc/gcov-io.c @@ -576,6 +576,55 @@ gcov_read_counter (void) return value; } +/* Mangle filename path of BASE and output new allocated pointer with + mangled path. */ + +char * +mangle_path (char const *base) +{ + /* Convert '/' to '#', convert '..' to '^', + convert ':' to '~' on DOS based file system. */ + const char *probe; + char *buffer = (char *)xmalloc (strlen (base) + 10); + char *ptr = buffer; + +#if HAVE_DOS_BASED_FILE_SYSTEM + if (base[0] && base[1] == ':') +{ + ptr[0] = base[0]; + ptr[1] = '~'; + ptr += 2; + base += 2; +} +#endif + for (; *base; base = probe) +{ + size_t len; + + for (probe = base; *probe; probe++) + if (*probe == '/') + break; + len = probe - base; + if (len == 2 && base[0] == '.' && base[1] == '.') + *ptr++ = '^'; + else + { +