[PATCH] D133480: [llvm-dwp] Get the DWO file from relative path if the absolute path is not valid

Arthur Eubanks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Oct 4 10:21:20 PDT 2022


aeubanks added inline comments.


================
Comment at: llvm/test/tools/llvm-dwp/X86/search_dwos.test:12
+
+clang++ -Xclang -fdebug-compilation-dir -Xclang "/tmp" -g -O0 -gsplit-dwarf a.cpp b.cpp -o main
+
----------------
steven.zhang wrote:
> dblaikie wrote:
> > aeubanks wrote:
> > > steven.zhang wrote:
> > > > dblaikie wrote:
> > > > > maybe use a less-likely-to-accidentally-exist path rather than `/tmp` (`/non-existent` or something?) (& any ideas how this works if the test runs on Windows? does the absolute path confuse things? maybe using a relative comp-dir like `non-existent` (without the leading `/`) would be better? Not sure how the other tests work already
> > > > Good point. `path-not-exists` I will use. 
> > > this test is failing on my machine because I have a `/tmp/a.dwo` with a different dwarf version. I think the checked in binaries are still using `/tmp`, could that be fixed?
> > Yeah, this probably should be recompiled with -fdebug-info-compilation-dir=some_relative_path (that way it's more readily portable to Windows, and would work reliably in the local test directory where we control what files exist/don't exist)
> > 
> > @steven.zhang could you please update the patch & post it for review along with the llvm-dwarfdump of the contents? (it's also possible this test could be modified to use assembly and llvm-mc to assemble it, rather than using checked in binary files, perhaps?)
> I will do it after my vacation (Oct 9)or someone could do it as it is a bit long time.
(next week is fine, I removed `/tmp/a.dwo` locally and now the test passes, just something that should eventually be fixed)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133480



More information about the llvm-commits mailing list