This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I have questions for reproducible build.
After supporting -no-canonical-prefixes and not enforcing absolute path for argv0, I assumes output of clang-cl (obj/stdout/stderr) does not contain absolute path iff all of following condition satisfied.
* pass -no-canonical-prefixes flag (this is for /showIncludes)
* do not pass debug info flag, /Z7, /Zi and /ZI (this is for remove filepath from obj)
* pass all include path in relative from (this is for /showIncludes)
Is this true?
If so, I can implement build cache sharing mechanism on goma backend for non-debug chromium build. This means windows chromium developer can share build cache even they build chrome in different build directory, and that will improve build time.
Another question is, is it possible to remove absolute path from obj file when we do debug build?
AFAIK, obj file of debug build contains absolute path for source file come from
https://github.com/llvm-project/llvm-project-20170507/blob/d3c09e61a0bb55525717252fbb7fc0b84e6fece9/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp#L1855
As clang/gcc do, I'd like to use fdebug-prefix-map for this filepath to relativize it.
If clang-cl emits relativized path for source filepath, will it broke behavior of lld, link.exe or debugger of visual studio?
I think that should be true -- but I haven't checked, and there might be things I haven't thought of. Another condition is probably that msvc_use_absolute_paths must be false (which is the default nowadays, but people for a well felt somewhat strongly it should default to true; allegedly clicking on diagnostics in MSVC doesn't work if it's not set. I haven't checked if that's still true; it reportedly used to be true 2 years ago or so).
For paths in debug info, it's a bit more tricky, but I have a rough idea what we could do which should work at least for files without local edits. As far as I know, pdb does require absolute paths, but it might be possible to work around it using the source indexing feature: The idea is that we give clang-cl a flag that makes it write dummy absolute paths like "c:\dummy_root\real_relative_path", and then let the linker write a default source index mapping c:\dummy_root to the local directory. (Making lld write the source index information seems like a good idea even without wanting no absolute paths in the pdb: currently, the linker writes the pdb and then a postbuild step writes additional stuff to the pdb for source indexing. It'd be better if the linker wrote the right bits in the first place.)
Thanks, I'll take care msvc_use_absolute_paths case.
Is it better to write dummy root than relative path? In chromium build, lld and clang-cl run in same cwd. So lld can restore fullpath when the path is written in relative form.
I think debuggers expect to see absolute paths in the debug info. Typically, IDEs are not run with the build directory as the CWD.
Didn't we have this problem with gdb recently on chromium-dev and everyone was advised to add some magic to their .gdbinit to work around the issue?
I think the dummy absolute path trick is the way to go, especially if we can do this source index mapping trick in LLD. It's what Microsoft does for all their software.
rnk: The proposal is that lld writes a pdb with absolute paths, but clang doesn't have to. clang writes codeview with relative paths, and then lld absolutizes them at link time. This gives us checkout-path-independent-cacheable compiles without changing anything for the debugger.
Initially I didn't think that would work, because it would require changing the size of various debug info records, but on further thought, I think it will work just fine.
Paths typically appear in two places:
1. The file checksum table (already has special handling for merging across objects)
2. As LF_STRING_ID records in type / item streams.
We might want to a sentinel that is more special than just "./" to prefix relative paths in LF_STRING_ID records, since identical string records get merged. For example, MSVC emits the original command line as string records, and if we blindly rewrite all paths starting with "./", we will end up making the command line appear as if it had used absolute paths.
Clang does not currently emit the original command line into the debug info yet. But, if LLD is linking objects compiled with MSVC, it will use the same string pool for paths that it uses for command line strings.
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/4ea122b62d8d7887a4d653c73bdc8ba50c890c2e
commit 4ea122b62d8d7887a4d653c73bdc8ba50c890c2e
Author: Takuto Ikuta <tikuta@chromium.org>
Date: Wed Jul 25 05:28:18 2018
Enable strip_absolute_paths_from_debug_symbol on windows build with goma by default
By this CL, we remove absolute path from obj files in windows build with goma.
And this allows to share build result even if it is built in different directory.
This will give faster build time to windows developers and also let goma team focus on cache hit build more.
This change removes absolute path from obj files, but lld linker absolutizes the path not to confuse debugger.
Also this CL enables the feature by default only for lld with goma build on windows.
Build stats of chrome on Z840 windows with -j1000
* is_debug=true and symbol_level=2
cache hit: 658 seconds
non-cache hit: 728 seconds
* is_debug=false and symbol_level=0
cache hit: 275 seconds
non-cache hit: 411 seconds
TODO: add build speed comparison of cache hit/no-hit build in symbol_level = 0 and symbol_level = 2
Bug: 712796
Change-Id: I88532a43addf693f93b30c96d08c8e93515d4344
Reviewed-on: https://chromium-review.googlesource.com/1143663
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577807}
[modify] https://crrev.com/4ea122b62d8d7887a4d653c73bdc8ba50c890c2e/build/config/compiler/BUILD.gn
Comment 1 by no...@chromium.org
, Apr 18 2017