The LTO streamer can pass the source directory through without calling remap_debug_filename. This path can escape into the debug information, which can make it hard to create reproducible results when using LTO. Specifically lto_output_location_1 writes the output of get_src_pwd into the stream without calling remap_debug_filename. This causes some complexity for Go tooling as discussed at the comment thread starting at https://go-review.googlesource.com/c/go/+/413974/15#message-4a4b317f08c2aee261b93c37c82a2bcab21830d8 . Basically, the Go tool is trying to get a reproducible build using LTO, and failing due to the inclusion of an unmapped directory.
const char *remapped = remap_debug_filename (xloc.file); if (ob->emit_pwd && remapped && !IS_ABSOLUTE_PATH (remapped)) { stream_pwd = true; ob->emit_pwd = false; } bp_pack_value (bp, stream_pwd, 1); if (stream_pwd) bp_pack_string (ob, bp, get_src_pwd (), true); It specifically streams out the pwd if there was a remapping happening and if the remapping was not an absolute path .... So what options are being passed here? is the remapping in one case to a relative path and then the cwd also gets remapped? Is that also being remapped to a relative path?
Yes, it's a relative path, such as #line 1 "cgo-gcc-prolog" These are dummy but informative line markers used to separate generated code from user-written code, so that compiler error messages report problems in the right place. The compiler is being executed in a temporary directory created during the build, so the working directory is meaningless. Other references to files in that temporary directory are rewritten by a -fdebug-prefix-map option. Unfortunately, that option fails to rename the working directory that is pulled in for the relative #line option.