[BOLT][DWARF] Get DWO file via relative path if the CompilationDir does not exist

[Jinjie-Huang]

In distributed builds, the DWARF CompilationDir is often invalid, causing BOLT to fail when locating DWO files. If the default path does not exist, it seems better to consider the DWOName as a relative path in this case?
And I think this approach should be more intuitive and aligns with DWARF-related tools like llvm-dwp(see: https://reviews.llvm.org/D133480#).

The implementation of this patch will try to search for the DWO file in the following order:

1. CompDirOverride + DWOName (if CompDirOverride specified)
2. CompilationDir + DWOName (if CompilationDir exists)
3. Current directory + DWOName (relative path as a fallback)

[llvmbot]

@llvm/pr-subscribers-bolt

Author: Jinjie Huang (Jinjie-Huang)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/154515.diff

2 Files Affected:

• (modified) bolt/lib/Core/BinaryContext.cpp (+6)
• (modified) bolt/lib/Rewrite/DWARFRewriter.cpp (+2)

diff --git a/bolt/lib/Core/BinaryContext.cpp b/bolt/lib/Core/BinaryContext.cpp
index 84f1853469709..6a56c8aa7cfa5 100644
--- a/bolt/lib/Core/BinaryContext.cpp
+++ b/bolt/lib/Core/BinaryContext.cpp
@@ -33,6 +33,7 @@
 #include "llvm/MC/MCSymbol.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Regex.h"
 #include <algorithm>
 #include <functional>
@@ -1640,6 +1641,11 @@ void BinaryContext::preprocessDWODebugInfo() {
       if (!opts::CompDirOverride.empty()) {
         sys::path::append(AbsolutePath, opts::CompDirOverride);
         sys::path::append(AbsolutePath, DWOName);
+      } else {
+        std::string CompDir = DwarfUnit->getCompilationDir();
+        sys::path::append(AbsolutePath, CompDir);
+        if (!sys::fs::exists(AbsolutePath) && sys::fs::exists(DWOName))
+          AbsolutePath = DWOName;
       }
       DWARFUnit *DWOCU =
           DwarfUnit->getNonSkeletonUnitDIE(false, AbsolutePath).getDwarfUnit();
diff --git a/bolt/lib/Rewrite/DWARFRewriter.cpp b/bolt/lib/Rewrite/DWARFRewriter.cpp
index 0c1a1bac6c72e..80b24a5561e81 100644
--- a/bolt/lib/Rewrite/DWARFRewriter.cpp
+++ b/bolt/lib/Rewrite/DWARFRewriter.cpp
@@ -1851,6 +1851,8 @@ void DWARFRewriter::writeDWOFiles(
     CompDir = opts::DwarfOutputPath.c_str();
   else if (!opts::CompDirOverride.empty())
     CompDir = opts::CompDirOverride;
+  else if (!sys::fs::exists(CompDir))
+    CompDir = ".";
 
   SmallString<16> AbsolutePath;
   sys::path::append(AbsolutePath, CompDir);

[ayermolo]

1. This sounds like a problem with the build system. We also use distributed builds. Our solution is to set comp_dir to ".", and then dwo_name is relative to whatever directory bolt is ran in.
   2). We also provide opts::CompDirOverride. Why is that not sufficient?

[Jinjie-Huang]

Thank you for your reply.

Yes, "-fdebug-compilation-dir=." for compiler or "CompDirOverride=." for llvm-bolt can perfectly resolve the issue here. But it seems that having the ability to get dwo from a relative path is also not bad? This consideration is that some other users might encounter this problem when launching distributed builds on local paths, and they may be faced with different build systems, or not familiar enough with BOLT-opts. And addressing this issue might also require some understanding of DWARF? which could require a bit of learning curve.

BTW, the behaviors of GDB and llvm-dwp also involve searching using both absolute and relative paths—probably based on similar considerations?

[ayermolo]

shouldn't this be appended to "."?

[Jinjie-Huang]

Umm, DWOName might be an absolute path... But in this case, using CompilationDir + DWOName would also be incorrect...

[ayermolo]

I guess if there is precedence...
Please add a test, and a warning that relative path will be used.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[Jinjie-Huang]

@ayermolo Currently it's changed to use make_absolute() joining DWOCompDir and DWOName. This is helpful when DWOName is already an absolute path (it will prevent the concatenation). Otherwise, if a .dwp file is specified, directly concatenating DWOCompDir and DWOName could trigger an asserting crash when emitting dwos.

PTAL, thanks.

[ayermolo]

Can you clarify on why we are building main.exe twice.

[Jinjie-Huang]

Done

[Jinjie-Huang]

@ayermolo Please have a look at this too. Thanks.

[ayermolo]

lgtm