[PATCH] D133480: [llvm-dwp] Get the DWO file using relative path instead of absolute path to make it work for distribution build

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D133480#3778767 <https://reviews.llvm.org/D133480#3778767>, @steven.zhang wrote:

> In D133480#3778054 <https://reviews.llvm.org/D133480#3778054>, @dblaikie wrote:
>
>> In D133480#3777196 <https://reviews.llvm.org/D133480#3777196>, @steven.zhang wrote:
>>
>>> In D133480#3777059 <https://reviews.llvm.org/D133480#3777059>, @dblaikie wrote:
>>>
>>>> I don't think this is correct - the dwp tool might be run from a different directory than the equivalent comp_dir and so treating these as cwd-of-dwp-relative paths seems problematic.
>>>>
>>>> I think the correct thing to do in the situation described is for the compilation to use -fdebug-compilation-dir <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fdebug-compilation-dir> to make the debug info portable - this will also ensure that a debugger can find the source and find the .dwo files even if they aren't packaged into a .dwp.
>>>
>>> Can we do it as what gdb did ? That is, getting the dwo from absolute path first, and if failed, get it from relative path ?
>>
>> I'm somewhat open to that, though I'd really encourage you to switch your build system/build flags so you don't have to keep adding functionality like that into other debug info consuming tools.
>
> Thank for the suggestion, and I appreciate it. The issue of adding the build flags is that, it will pollute the remote cache. For example:
>
> - building in workspace A: adding compilation option -fdebug-compilation-dir=path_to_workspace_A, and the objects will be cached in the remote build server.
>
> - building in workspace B: adding compilation option -fdebug-compilation-dir=path_to_workspace_B, we cannot get the objects from remote cache though all the source code didn't change. We have to rebuild it as the compilation option changed.
>
> If with relative path, we don't need to rebuild the objects as everything is unchanged. Remote cache is important to large project to speed up the building.
>
> I will extend current implementation to support relative path.

Ah, sorry I didn't fully explain - yes (for context: I work at Google/on the compiler we use in the internal version of Bazel - so I'm familiar with the complexities of distributed and reusable build caches). Specifically, if the comp_dir is basically unusable (because if it's accurate/absolute for a local user, it's useless to another user, and it can't be whatever's on the build node either) you can use `-fdebug-compilation-dir=.` (I think at Google we use `/proc/cwd` to be precise) and then you'll get the current-working-directory relative behavior without consumers having to implement any special case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133480/new/

https://reviews.llvm.org/D133480