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

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

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

> Pavel, your last comment lost me completely.  How can I test the code I added to lldb if I don't run lldb?  I am a complete newbie at writing test cases so there's probably something basic I'm missing?  How would I observe the value of the variable without running lldb?  Also, if the program doesn't contain 'main', won't the compiler complain?  Is there an existing test that does what you're suggesting that I could look at?

Sorry, I meant running the inferior -- you do definitely need to run lldb :)

And we can avoid the need for the main function by pointing lldb directly at the object file. As long as you don't try to run the file, lldb (mostly) does not care whether it's dealing with a full binary or just an object file. A lot of the .s tests in this directory use that approach, but most of them don't use split dwarf, so I don't know of a file you could copy verbatim. However, you could try to look at `dwarf5-split.s`, which does something pretty similar with a dwp file.

I'd imagine the test could look something like:

  ## As before
  # RUN: llvm-mc --filetype=obj --triple x86_64-pc-linux %s -o %t.o
  # RUN: llvm-objcopy --split-dwo=%T/dwo-relative-path.dwo %t.o
  
  ## No linking
  
  # RUN: cd ../..
  
  # RUN: %lldb %t.o -o "target variable x" -b 2>&1 | FileCheck %s
  
  # CHECK: x = 10
  
  ## Debug info for "int x = 10;"


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

https://reviews.llvm.org/D97786