Hi Richard, I added Sergio to the CC since he was looking at debuginfo/DWARF relative paths created by -fdebug-prefix-map in Debian and having trouble making them work correctly. Maybe he has some feedback how to make this work.
On Mon, Aug 15, 2022 at 12:13:28PM +0100, Richard Purdie via Gcc wrote: > I'm wondering if we'd be able to improve path handling in the -f*- > prefix-map compiler options to cover relative paths? > [...] > In case it helps, my background on what I'm working on and why we'd > find this useful follows: > > I work on Yocto Project which cross compiles complete software stacks, > we use gcc heavily and the resulting builds are all around us. We care > deeply about build reproducibility. > > With autotools, we long ago realised that we were best off separating > the source and the build output where we could and to do it we used > relative paths, which removed a lot of problematic hardcoded paths in > our output. > > More recently we've been using -fdebug-prefix-map and -fmacro-prefix- > map (we need both since some of binutils doesn't seem to support the > combined version yet). We use the debug information (split separately) > to support on target debugging but where relative paths were used, we > miss information as the remapping either doesn't happen correctly or is > mangled. We'd like to fix our debug output but we're finding that hard > without relative path support for *prefix-map. I might be misinterpreting the issue you are seeing. But one problem with debuginfo/DWARF is that relative source paths aren't clearly defined. If you move or install the executable or (split) debug file out of the build directory a DWARF reader has no way to know what the paths are relative to. So for DWARF the paths always have to be absolute (they can still be relative to the compilation dir (DW_AT_comp_dir), but at least that has to be absolute (and the compiler should turn any relative path into an absolute one or make sure they are relative to an absolute compilation directory path). The problem with that is a) it makes the binary (debuginfo) output dependent on the build srcdir and builddir and b) to support debugging/tracing/profiling tools the user has to install the (debug) sources under those exact same directories on their local machine. One way around this is to use -fdebug-prefix-map with an absolute paths under which you will also install any source files. Or to use debugedit [*] after the build to rewrite the build dir path to something like /usr/debug/src/<package-version-release-archa> which is what some distros do. e.g. Fedora has (one or more) binary package, a debuginfo package for the .debug files (optionally installed under /usr/lib/debug) and debugsource package for the debug source files (optionally installed under /usr/debug/src). These packages can then also be used to dynamically find any debug or source file when indexed by debuginfod [**]. Using known absolute paths generated with debugedit or -fdebug-prefix-map makes sure the paths used in the debuginfo/DWARF are always the same independent from the current srcdir or builddir to make them reproducible. And the user/tools don't have to guess what the relative paths are relative to. And it makes it so you can install the (debug) source files of all packages/versions/arches in parallel without file conflicts. Cheers, Mark [*] https://sourceware.org/debugedit/ [**] http://debuginfod.elfutils.org/
