dblaikie added a comment. In D97786#2972153 <https://reviews.llvm.org/D97786#2972153>, @pfaffe wrote:
> This change breaks all existing uses of relative comp_dirs that don't > accidentally make all of them relative to the executable's directory already. > > It's easy to construct broken use cases: Consider compiling your program like > `clang -g ./src/src.c -gsplit-dwarf -o ./out/src > -fdebug-prefix-map=$(pwd)=.`. This will create `src.dwo` in $(pwd) and set > the DW_AT_comp_dir of `src` to "."; the change makes it impossible to load > `src.dwo`. > > The problem is easy to see in this slightly constructed example and could be > fixed here by moving around the dwo files or setting the prefix to '..' to > make it point to the executable. But that's not always possible! What if we > have a static library that gets linked into multiple executables in different > locations? What do we set comp_dir to in the library objects? > > The change also introduces different behavior for loading dwos vs. source > files. The latter will still be loaded relative to the CWD. This doesn't solve all use cases/it's not a terribly general purpose situation - using -fdebug-prefix-map/-fdebug-compilation-dir requires knowledge of these limitations/how to use these features together. (though I agree that changes in this area should apply to all relative comp_dir lookups - source and dwo files alike, rather than handling one group differently from the other when they're all defined as comp_dir relative) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97786/new/ https://reviews.llvm.org/D97786 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
