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

Pavel Labath via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 2 11:42:56 PST 2021


labath added a comment.

In D97786#2598100 <https://reviews.llvm.org/D97786#2598100>, @cmtice wrote:

> re "GDB does it this way" -- I am also writing/submitting a patch to get GDB to change this behavior.

Ah, I see. That changes the picture, I'd say. If gdb folks go along with that, then I don't see any problems here. I see just one small issue to nail down -- what exactly is the path relative to? The executable file, or the file containing the debug info (in the `objcopy --strip-debug/--only-keep-debug` scenario)? I think the latter would be /slightly/ more useful, as one can imagine shipping the dwos in /usr/lib/debug, next to the `.debug` file (though I hope that in reality, everyone will just ship the dwp file). I think this is actually what this patch implements.



================
Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1646-1652
+      ModuleSpec module_spec;
+      module_spec.GetFileSpec() = m_objfile_sp->GetFileSpec();
+      module_spec.GetSymbolFileSpec() =
+          FileSpec(m_objfile_sp->GetModule()->GetFileSpec().GetPath());
+      llvm::StringRef exe_dir =
+          module_spec.GetFileSpec().GetDirectory().GetStringRef();
+      dwo_file.PrependPathComponent(exe_dir);
----------------
All of this is basically  just `dwo_file.PrependPathComponent(m_objfile_sp->GetFileSpec().GetDirectory().GetStringRef())`, is it not?


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

https://reviews.llvm.org/D97786



More information about the llvm-commits mailing list