[lldb] Add more ways to find split DWARF files

[DavidSpickett]

Summary

Fixes #28667

There's a bunch of ways to end up building split DWARF where the
DWO file is not next to the program file. On top of that you may
distribute the program in various ways, move files about, switch
machines, flatten the directories, etc.

This change adds a few more strategies to find DWO files:

• Appending the DW_AT_COMP_DIR and DWO name to all the debug search paths.
• Appending the same to the binary's dir.
• Appending the DWO name (e.g. a/b/foo.dwo) to all the debug search paths.
• Appending the DWO name to the binary's location.
• Appending the DWO filename (e.g. foo.dwo) to the debug search paths.
• Appending the DWO filename to the binary's location.

They are applied in that order and some will be skipped
if the DW_AT_COMP_DIR is relative or absolute, same for
the DWO name (though that seems to always be relative).

This uses the setting target.debug-file-search-paths, which
is used for DWP files already.

The added tests likely do not cover every part of the
strategies listed, it's a best effort.

[DavidSpickett]

For https://github.com/llvm/llvm-project/issues/28667

[DavidSpickett]

Cleanup, add testing.

[DavidSpickett]

https://github.com/llvm/llvm-project/issues/28667 is the github issue.

@lenary This fixes your reproducer, if you have any more ways to confuse lldb please try them with this.

[clayborg]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1735

Maybe we can also check the debug info search paths to see if they contain just the basename in case someone sends you a binary and any needed .dwo files?

So if we have a DWO path of "/users/someone/build/foo.dwo", we would check each of the debug info search paths for:

path + dwo_file.GetFilename()

This would allow someone to send a binary to someone else and allow them to load it up.

But any such search might belong down below this entire if/else statement when the file isn't found:

if (!found) {
  // Search for debug info path + basename...
}

1844

Here is where we might think about doing the debug info search path + basename searches since it doesn't matter if the .dwo file original path was relative or not.

[clayborg]

We are also looking for a way to locate .dwo files at Meta. One idea we came up with is to add a setting that can be set:

(lldb) settings set symbols.locate-dwo-script /path/to/locate-dwo.py

Any specified scripts would be expect to contain a python function:

def locate_dwo(exe_path: lldb.SBFileSpec, dwo_path: lldb.SBFileSpec, dwo_id: str) -> lldb.SBFileSpec
  # Add code to locate the .dwo file here...

All of our binaries are built in a "buck-out" directory and the .dwo file paths are relative this to folder regardless of the DW_AT_comp_dir value. If we pass the executable into this function, we can search for "/buck-out/" in the path, and then use the first part of the path as a prefix and return a valid path.

This kind of solution might allow distributed build systems to not have to download all of the .dwo files until they are requested and the script could download them and return a path.

The current solution in this patch is nice and simple and would also work, but it would require us to know up front where these directories are so that we can set the setting correctly which is what we are trying to avoid as if someone tries to debug and doesn't see variables due to not being able to find a .dwo file, then some turn the "printf pro".

[DavidSpickett]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1735

Good idea, I'll write a test for that scenario and see if it makes sense here or in a follow up.

[DavidSpickett]

We are also looking for a way to locate .dwo files at Meta. One idea we came up with is to add a setting that can be set:
(lldb) settings set symbols.locate-dwo-script /path/to/locate-dwo.py

Probably best bring this up on Discourse for a wider audience as I'm not up to date on all the search methods, I just dived into this one in particular. First thought is it sounds a bit like what debuginfod is supposed to do, but I don't know the details of that at the moment.

[DavidSpickett]

Rebase

[DavidSpickett]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1735

https://reviews.llvm.org/D158182

[clayborg]

Just one question if we should still try all of your new code if we have a full path to a DW_AT_comp_dir, but we don't find the .dwo file, should be allow your code to run and still try to just append the relative "dwo_name" (without comp dir) to each of the search paths?

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1801

If "found == false" here, do we want to fall through to the "else" clause below? This would mean we have a full path to a DW_AT_comp_dir, but we didn't find the .dwo file and "dwo_name" is relative, so maybe we should try to use the relative "dwo_name" below without the comp dir if not found?

1804–1805

On major issue we have here is if someone creates a target first, then sets the debug file search paths, then this will always fail because Target::GetDefaultDebugFileSearchPaths() gets the global target settings. This is because before we have a target, if any target settings get set, they get set in this global target settings object. Then each time you create a target, it will get a copy of these global settings. So this would work:

(lldb) settings set target.debug-file-search-paths /my/objfiles
# Global target settings are set above
(lldb) target create a.out
(lldb) run
...

This wouldn't:

(lldb) target create a.out
(lldb) settings set target.debug-file-search-paths /my/objfiles
# Current target settings are set above, not the global settings
(lldb) run
...

Because the global settings have nothing for the "target.debug-file-search-paths", but the current lldb_private::Target that was created by "target create a.out" does have it set, but that isn't what we are getting here.

We don't have access to the current target anywhere in lldb_private::Module and its lldb_private::ObjectFile or lldb_private::SymbolFile because lldb_private::Module can be used in multiple targets, so the module doesn't know what target it is in. This isn't something that needs to be solved here, but we should understand the limitations.

[DavidSpickett]

In the interests of my own sanity I've squashed the subsequent review into this one
and applied the suggestions from both.

Also I changed the tests to look for a global so we don't have to update the
line number all the time.

[DavidSpickett]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1801

I've done this in this latest revision.

1844

This is now done above, either relative or not will end up trying paths + dwoname and paths + filename.

[DavidSpickett]

Use *.dwo in commands since I'm not sure the DWO name will be the
same everywhere. The specific name isn't important, we know there's
only going to be one.

[clayborg]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1830

Rename to "dwo_name_spec"? I think we can use this down below in following inline comments

1833

Rename to "binary_directory"?

1837–1839

Should we only do this if "dwo_name" is relative? Also if "comp_dir" is relative, do we want to add another path to search here?

[DavidSpickett]

Rename as suggested.

[DavidSpickett]

In the fallback, only check binary dir + dwo name if the dwo name is relative.

[DavidSpickett]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1837–1839

Should we only do this if "dwo_name" is relative?

Done.

Also if "comp_dir" is relative, do we want to add another path to search here?

binary dir + relative comp dir is covered in the first set of checks around:

// if DW_AT_comp_dir is relative, it should be relative to the location...

[clayborg]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1732–1796

If we have no comp_dir, then we should still search for the file right? We are returning early here without trying to use the search paths?

1808

Will this return false for a symlink to a directory?

[DavidSpickett]

Log when comp dir not found and carry on to fallback search.

Add a test for the search path being a symlink.

[DavidSpickett]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1732–1796

Refactored this to log and carry on to the later searches.

We don't test for this situation at all so it's likely very rare, which means logging it is fine. Standard advice on unexplained failures to find things is check the logs.

1808

In this case no because comp_dir was always being added to it, unless the result of that was also pointing to a symlink.

I have added a test case to check you can set the search path to a symlink, I'm not sure of an easy way to do that for comp_dir.

[DavidSpickett]

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

1808

The underlying filesystem does have different types for a directory and a symlink, so the general answer is yes it appears that IsDirectory would return false for a symlink.

Which you'd think would affect the later searches using the search path only, but it doesn't. So maybe resolving helps there, not sure. End result is good anyway.

[clayborg]

Thanks a lot for acting on all feedback and getting all of the edge cases! LGTM

[DavidSpickett]

No problem. I doubt this is all of them but at least users can now workaround the gaps using the setting, and hack up one of these test cases to make reproducers.

[JDevlieghere]

Looks like this broke the X86 bot: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/59815/

[DavidSpickett]

From what I gather, split dwarf isn't a thing on Darwin so I've relanded with the tests skipped (https://github.com/llvm/llvm-project/commit/b1f14d647300b0ed003fa7c24af311b11605d009).

[dblaikie]

Any chance we could simplify this situation and have dwo searches use exactly the same/shared logic as source file searches? It seems like the dwarf spec intent was for that to be the case.

I don't mind adding more ways to find things, but think it'd be useful if we only had one set of rules instead of two, to prevent divergence.

(The script idea from Greg sounds ok too (but ideally, also in the context of one search system for both source and dwo) - but yeah, maybe invasive enough that it merits a separate/broader design discussion)

[DavidSpickett]

Any chance we could simplify this situation and have dwo searches use exactly the same/shared logic as source file searches?

I'm not sure what exactly this means, can you clarify?

I know that DWP and DWO have different search functions, that could certainly be unified. Not sure how source files work.

[clayborg]

In D157609#4644194, @DavidSpickett wrote:

Any chance we could simplify this situation and have dwo searches use exactly the same/shared logic as source file searches?

I'm not sure what exactly this means, can you clarify?

I know that DWP and DWO have different search functions, that could certainly be unified. Not sure how source files work.

Source file search paths and debug info search paths are different in LLDB. GDB had one setting IIRC that handled both. These settings have been in LLDB for a while so I wouldn't recommend changing this up at this point.

[dblaikie]

In D157609#4645298, @clayborg wrote:

In D157609#4644194, @DavidSpickett wrote:

Any chance we could simplify this situation and have dwo searches use exactly the same/shared logic as source file searches?

I'm not sure what exactly this means, can you clarify?

I know that DWP and DWO have different search functions, that could certainly be unified. Not sure how source files work.

Source file search paths and debug info search paths are different in LLDB. GDB had one setting IIRC that handled both. These settings have been in LLDB for a while so I wouldn't recommend changing this up at this point.

I don't think that's a great motivation to diverge them further.

We could make the DWO search fallback to the source search - and add new features to the source search if needed. That'd at least align things a bit closer, rather than diverging further.

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

if (!dwo_name) {
     unit.SetDwoError(Status::createWithFormat(
         "missing DWO name in skeleton DIE {0:x16}", cu_die.GetOffset()));
     return nullptr;
   }
 
   if (std::shared_ptr<SymbolFileDWARFDwo> dwp_sp = GetDwpSymbolFile())
     return dwp_sp;
 
-  const char *comp_dir = nullptr;
   FileSpec dwo_file(dwo_name);
   FileSystem::Instance().Resolve(dwo_file);
-  if (dwo_file.IsRelative()) {
-    comp_dir = cu_die.GetAttributeValueAsString(dwarf_cu, DW_AT_comp_dir,
-                                                nullptr);
-    if (!comp_dir) {
-      unit.SetDwoError(Status::createWithFormat(
-          "unable to locate relative .dwo debug file \"{0}\" for "
-          "skeleton DIE {1:x16} without valid DW_AT_comp_dir "
-          "attribute",
-          dwo_name, cu_die.GetOffset()));
-      return nullptr;
-    }
+  bool found = false;
+
+  const FileSpecList &debug_file_search_paths =
+      Target::GetDefaultDebugFileSearchPaths();
+  size_t num_search_paths = debug_file_search_paths.GetSize();
+
+  // It's relative, e.g. "foo.dwo", but we just to happen to be right next to
+  // it. Or it's absolute.
+  found = FileSystem::Instance().Exists(dwo_file);
 
+  if (!found) {
+    // It could be a relative path that also uses DW_AT_COMP_DIR.
+    const char *comp_dir =
+        cu_die.GetAttributeValueAsString(dwarf_cu, DW_AT_comp_dir, nullptr);
+
+    if (comp_dir) {
       dwo_file.SetFile(comp_dir, FileSpec::Style::native);
-    if (dwo_file.IsRelative()) {
+      if (!dwo_file.IsRelative()) {
+        FileSystem::Instance().Resolve(dwo_file);
+        dwo_file.AppendPathComponent(dwo_name);
+        found = FileSystem::Instance().Exists(dwo_file);
+      } else {
+        FileSpecList dwo_paths;
+
         // if DW_AT_comp_dir is relative, it should be relative to the location
         // of the executable, not to the location from which the debugger was
         // launched.
-      dwo_file.PrependPathComponent(
+        FileSpec relative_to_binary = dwo_file;
+        relative_to_binary.PrependPathComponent(
             m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef());
+        FileSystem::Instance().Resolve(relative_to_binary);
+        relative_to_binary.AppendPathComponent(dwo_name);
+        dwo_paths.Append(relative_to_binary);
+
+        // Or it's relative to one of the user specified debug directories.
+        for (size_t idx = 0; idx < num_search_paths; ++idx) {
+          FileSpec dirspec = debug_file_search_paths.GetFileSpecAtIndex(idx);
+          dirspec.AppendPathComponent(comp_dir);
+          FileSystem::Instance().Resolve(dirspec);
+          if (!FileSystem::Instance().IsDirectory(dirspec))
+            continue;
+
+          dirspec.AppendPathComponent(dwo_name);
+          dwo_paths.Append(dirspec);
+        }
+
+        size_t num_possible = dwo_paths.GetSize();
+        for (size_t idx = 0; idx < num_possible && !found; ++idx) {
+          FileSpec dwo_spec = dwo_paths.GetFileSpecAtIndex(idx);
+          if (FileSystem::Instance().Exists(dwo_spec)) {
+            dwo_file = dwo_spec;
+            found = true;
+          }
+        }
+      }
+    } else {
+      Log *log = GetLog(LLDBLog::Symbols);
+      LLDB_LOGF(log,
+                "unable to locate relative .dwo debug file \"%s\" for "
+                "skeleton DIE 0x%016" PRIx64 " without valid DW_AT_comp_dir "
+                "attribute",
+                dwo_name, cu_die.GetOffset());
+    }
+  }
+
+  if (!found) {
+    // Try adding the DW_AT_dwo_name ( e.g. "c/d/main-main.dwo"), and just the
+    // filename ("main-main.dwo") to binary dir and search paths.
+    FileSpecList dwo_paths;
+    FileSpec dwo_name_spec(dwo_name);
+    llvm::StringRef filename_only = dwo_name_spec.GetFilename();
+
+    FileSpec binary_directory(
+        m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef());
+    FileSystem::Instance().Resolve(binary_directory);
+
+    if (dwo_name_spec.IsRelative()) {
+      FileSpec dwo_name_binary_directory(binary_directory);
+      dwo_name_binary_directory.AppendPathComponent(dwo_name);
+      dwo_paths.Append(dwo_name_binary_directory);
+    }
+
+    FileSpec filename_binary_directory(binary_directory);
+    filename_binary_directory.AppendPathComponent(filename_only);
+    dwo_paths.Append(filename_binary_directory);
+
+    for (size_t idx = 0; idx < num_search_paths; ++idx) {
+      FileSpec dirspec = debug_file_search_paths.GetFileSpecAtIndex(idx);
+      FileSystem::Instance().Resolve(dirspec);
+      if (!FileSystem::Instance().IsDirectory(dirspec))
+        continue;
+
+      FileSpec dwo_name_dirspec(dirspec);
+      dwo_name_dirspec.AppendPathComponent(dwo_name);
+      dwo_paths.Append(dwo_name_dirspec);
+
+      FileSpec filename_dirspec(dirspec);
+      filename_dirspec.AppendPathComponent(filename_only);
+      dwo_paths.Append(filename_dirspec);
+    }
+
+    size_t num_possible = dwo_paths.GetSize();
+    for (size_t idx = 0; idx < num_possible && !found; ++idx) {
+      FileSpec dwo_spec = dwo_paths.GetFileSpecAtIndex(idx);
+      if (FileSystem::Instance().Exists(dwo_spec)) {
+        dwo_file = dwo_spec;
+        found = true;
+      }
     }
-    FileSystem::Instance().Resolve(dwo_file);
-    dwo_file.AppendPathComponent(dwo_name);
   }
 
-  if (!FileSystem::Instance().Exists(dwo_file)) {
+  if (!found) {
     unit.SetDwoError(Status::createWithFormat(
         "unable to locate .dwo debug file \"{0}\" for skeleton DIE "
         "{1:x16}",
         dwo_file.GetPath().c_str(), cu_die.GetOffset()));
 
     if (m_dwo_warning_issued.test_and_set(std::memory_order_relaxed) == false) {
       GetObjectFile()->GetModule()->ReportWarning(
           "unable to locate separate debug file (dwo, dwp). Debugging will be "

lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-path-symlink-relative-compdir.c

+/// Check that LLDB uses the paths in target.debug-file-search-paths to find
+/// split DWARF files with a relative DW_AT_comp_dir set, when the program file
+/// has been moved and/or we're executing it from another directory. Even when
+/// the provided search path is actually a symlink to the real location.
+// UNSUPPORTED: system-windows
+// RUN: rm -rf %t.compdir/ %t.e/
+// RUN: mkdir -p %t.compdir/a/b/c/d/
+// RUN: cp %s %t.compdir/a/b/c/d/main.c
+// RUN: cd %t.compdir/a/b/
+/// The produced DWO is named c/d/main-main.dwo, with a DW_AT_comp_dir of a/b.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. c/d/main.c -o c/d/main
+// RUN: cd ../../..
+/// Move only the program, leaving the DWO file in place.
+// RUN: mv %t.compdir/a/b/c/d/main %t.compdir/a/
+/// Create a symlink to the compliation dir, to use instead of the real path.
+// RUN: ln -s %t.compdir %t.symlink_to_compdir
+/// Debug it from yet another path.
+// RUN: mkdir -p %t.e/
+// RUN: cd %t.e
+/// DWO should be found by following using symlink + a/b/ + c/d/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/main \
+// RUN:   -O "settings append target.debug-file-search-paths %t.symlink_to_compdir" \
+// RUN:   -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }

lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-dwoname-absolute-compdir.c

+/// Check that LLDB uses the paths in target.debug-file-search-paths to find
+/// split DWARF files with DW_AT_comp_dir set to some absolute path, when
+/// the program file and DWO have been moved and/or we're executing from
+/// another directory. Specifically when the DWO has been moved to another
+/// directory but is still at it's name. Here, %t.compdir/c/d/main-main.dwo.
+// RUN: rm -rf %t.compdir/ %t.e/
+// RUN: mkdir -p %t.compdir/a/b/c/d/
+// RUN: cp %s %t.compdir/a/b/c/d/main.c
+// RUN: cd %t.compdir/a/b/
+/// The produced DWO is named c/d/main-main.dwo, with a non-relative
+/// DW_AT_comp_dir of <pathtobuild>/a/b
+// RUN: %clang_host -g -gsplit-dwarf c/d/main.c -o c/d/main
+// RUN: cd ../../..
+/// Move the program.
+// RUN: mv %t.compdir/a/b/c/d/main %t.compdir/a/
+/// Move the DWO but keep it at the path in in its name.
+// RUN: mkdir -p %t.compdir/c/d/
+// RUN: mv %t.compdir/a/b/c/d/*.dwo %t.compdir/c/d/
+/// Debug it from yet another path.
+// RUN: mkdir -p %t.e/
+// RUN: cd %t.e
+/// LLDB should find in %t.compdir.
+// RUN: %lldb --no-lldbinit %t.compdir/a/main \
+// RUN:   -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN:   -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }
 No newline at end of file

lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-absolute-compdir.c

+/// Check that LLDB uses the paths in target.debug-file-search-paths to find
+/// split DWARF files with DW_AT_comp_dir set to some non-relative path, when
+/// the program file and DWO have been moved and/or we're executing from another
+/// directory. Specifically when the DWO is not at it's "name", here we move
+/// it to %t.compdir/main-main.dwo and it's name is c/d/main-main.dwo.
+// RUN: rm -rf %t.compdir/ %t.e/
+// RUN: mkdir -p %t.compdir/a/b/c/d/
+// RUN: cp %s %t.compdir/a/b/c/d/main.c
+// RUN: cd %t.compdir/a/b/
+/// The produced DWO is named c/d/main-main.dwo, with a non-relative
+/// DW_AT_comp_dir of <pathtobuild>/a/b
+// RUN: %clang_host -g -gsplit-dwarf c/d/main.c -o c/d/main
+// RUN: cd ../../..
+/// Move the program.
+// RUN: mv %t.compdir/a/b/c/d/main %t.compdir/a/
+/// Move the DWO.
+// RUN: mv %t.compdir/a/b/c/d/*.dwo %t.compdir
+/// Debug it from yet another path.
+// RUN: mkdir -p %t.e/
+// RUN: cd %t.e
+/// LLDB should find in %t.compdir.
+// RUN: %lldb --no-lldbinit %t.compdir/a/main \
+// RUN:   -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN:   -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }
 No newline at end of file

lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-filename-only-relative-compdir.c

+/// Check that when LLDB is looking for a relative DWO it uses the debug search
+/// paths setting. If it doesn't find it by adding the whole relative path to
+/// of DWO it should try adding just the filename (e.g. main.dwo) to each debug
+/// search path.
+// RUN: rm -rf %t.compdir/
+// RUN: mkdir -p %t.compdir/a/b/
+// RUN: cp %s %t.compdir/a/b/main.c
+// RUN: cd %t.compdir/a/
+/// The produced DWO is named /b/main-main.dwo, with a DW_AT_comp_dir of a/.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. b/main.c -o b/main
+// RUN: cd ../..
+/// Move the DWO file away from the expected location.
+// RUN: mv %t.compdir/a/b/*.dwo %t.compdir/
+/// LLDB won't find the DWO next to the binary or by adding the relative path
+/// to any of the search paths. So it should find the DWO file at
+/// %t.compdir/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/b/main \
+// RUN:   -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN:   -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }
 No newline at end of file

lldb/test/Shell/SymbolFile/DWARF/dwo-debug-file-search-paths-relative-compdir.c

+/// Check that LLDB uses the paths in target.debug-file-search-paths to find
+/// split DWARF files with a relative DW_AT_comp_dir set, when the program file
+/// has been moved and/or we're executing it from another directory.
+// RUN: rm -rf %t.compdir/ %t.e/
+// RUN: mkdir -p %t.compdir/a/b/c/d/
+// RUN: cp %s %t.compdir/a/b/c/d/main.c
+// RUN: cd %t.compdir/a/b/
+/// The produced DWO is named c/d/main-main.dwo, with a DW_AT_comp_dir of a/b.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. c/d/main.c -o c/d/main
+// RUN: cd ../../..
+/// Move only the program, leaving the DWO file in place.
+// RUN: mv %t.compdir/a/b/c/d/main %t.compdir/a/
+/// Debug it from yet another path.
+// RUN: mkdir -p %t.e/
+// RUN: cd %t.e
+/// LLDB won't find the DWO next to the binary or in the current dir, so it
+/// should find the DWO file by doing %t.compdir/ + a/b/ + c/d/main-main.dwo.
+// RUN: %lldb --no-lldbinit %t.compdir/a/main \
+// RUN:   -O "settings append target.debug-file-search-paths %t.compdir" \
+// RUN:   -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }

lldb/test/Shell/SymbolFile/DWARF/dwo-relative-filename-only-binary-dir.c

+/// Check that LLDB can find a relative DWO file next to a binary just using the
+/// filename of that DWO. For example "main.dwo" not "a/b/main.dwo".
+// RUN: rm -rf %t.compdir/
+// RUN: mkdir -p %t.compdir/a/b/
+// RUN: cp %s %t.compdir/a/b/main.c
+// RUN: cd %t.compdir/a/
+/// The produced DWO is named b/main-main.dwo, with a DW_AT_comp_dir of a/.
+// RUN: %clang_host -g -gsplit-dwarf -fdebug-prefix-map=%t.compdir=. b/main.c -o b/main
+// RUN: cd ../..
+/// Move binary and DWO out of expected locations.
+// RUN: mv %t.compdir/a/b/main %t.compdir/
+// RUN: mv %t.compdir/a/b/*.dwo %t.compdir/
+// RUN: %lldb --no-lldbinit %t.compdir/main \
+// RUN:   -o "b main" -o "run" -o "p num" --batch 2>&1 | FileCheck %s
+
+// CHECK-NOT: warning: {{.*}}main unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
+// CHECK: (int) 5
+
+int num = 5;
+
+int main(void) { return 0; }
 No newline at end of file