[PATCH] D97786: LLDB: Use path relative to binary, not relative to debugger CWD, for finding .dwo files.

[David Blaikie via Phabricator via llvm-commits]

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