On Mon, 2022-08-15 at 17:15 +0000, Joseph Myers wrote: > On Mon, 15 Aug 2022, Richard Purdie via Gcc wrote: > > > Currently it works well for absolute paths but if a file uses a > > relative path or a path with a symlink in, or a non-absolute path, it > > will miss those cases. For relative paths in particular it is > > problematic as you can't easily construct a compiler commandline that > > would cover all relative path options. > > I'd expect a relative path to be naturally relocatable without needing to > be remapped. (For example, DW_AT_comp_dir would be relocated in debug > info, but there would be no need to relocate the paths to individual files > that are relative to DW_AT_comp_dir.) > > Is the issue that you're using relative paths between two directories that > don't have a fixed relative path between them, such as between the build > and source directories, as opposed to relative paths within the source > directory or within the build directory?
Yes, that is the issue. We build with separate build and source directories with a relative path between them and that relation doesn't work on target, particularly for installed binaries. It is a general problem but particularly where we build multiple components from the one shared source tree as those paths become multiple levels deep which makes creating a source layout on target to match even harder. > > which address a realpath() call into the prefix mapping code. I did > > That would run the risk of breaking relocation for anyone who has > deliberately used the paths they pass to the compiler (possibly involving > symlinks, for example) in their remapping options - not expecting a > further level of processing to be applied to those paths before remapping. It would be a change in behaviour but I'm not sure how many people would be relying on that or if they even should be. A relative path would only be relocated if it did match something in the prefix-map variables so this would be controllable. Cheers, Richard
