https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #8 from vit9696 <vit9696 at protonmail dot com> --- > Sure, well, I can imagine introducing something similar to what we have for > gcov: > > $ gcov --help | grep hash > -x, --hash-filenames Hash long pathnames Yes, that would likely solve the issue, though in an unexpected way for me. However, while it is highly unlikely, I can expect collisions in this case, and would rather not risk it. > Well, I don't fully understand your needs. On one hand, you're unhappy about > the relative placement of the .gcda files. And on the other, you don't like -fprofile-dir=/path. Note you can copy the *.gcda files to an arbitrary location and use it for -fprofile-use=/some/path. That does not require knowledge of -fprofile-generate=/original/path. > I'm sorry for defensive argumentation, but believe me the .gcda filename > handling is very complex even in the current situation. Sorry. I guess there are multiple issues that arose on our side, which also made the report rather confusing. What we have here is a CI building code on different nodes at different paths (they are different, because multiple builds can run on the same node). Depending on various meta information like node name, branch name, and so on, which is present in the build prefix, the gcda files we get may be too long and randomly exceed the 200 byte path limitation we have. The thing is, our source paths do not exceed this limitation, and the problem is just with the prefix, which we would like to entirely strip. It would have worked fine if: (a) build directory relative paths were stored as the .gcda paths (/a/b/c/master/path/to/file.gcda becomes path/to/file.gcda) or (b) special prefix + build directory relative paths were stored as the .gcda paths (/a/b/c/master/path/to/file.gcda becomes /special/path/to/file.gcda). Thus the need for the option. Going this way also allows us to resolve a second issue. To speedup testing we prebuild most of the source code on one machine, and then distribute the resulting .o and .a files to other machines. Currently this is unimplemented for coverage, but we would also like to distribute .gcno files the same way, and avoid the need to compile on the node when doing coverage gathering. The issue here is that different processes on the target may share some object code (e.g. libraries). Dumping coverage for different processes means that we have to produce multiple .gcda files on the node from the same .gcda paths in the object code. I.e. they not only depend on the build node path, but also the process we are dumping the information from. To be able to produce an adequate .gcda tree on the node with the current implementation we would have to remember all the original build node prefixes of the library code. Otherwise we would be unable to remap build node path to a run node path for a particular process (to get the .gcno files for instance). However, if all userspace code is compiled with e.g. /special prefix, and the original build prefix is stripped, only one path needs to be handled: /special/lib1/path/to/file1.gcda /special/lib2/path/to/file2.gcda /special/lib3/path/to/file3.gcda /special/path/to/source.gcda Hope this makes the situation clearer, and helps to understand why the particular option is desired.
