diff options
| author | Caroline Tice <cmtice@google.com> | 2021-04-15 13:36:23 -0700 |
|---|---|---|
| committer | Caroline Tice <cmtice@google.com> | 2021-04-15 14:43:47 -0700 |
| commit | b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc (patch) | |
| tree | dbfe16a4c15307af11d6c36ff998c043deb8b0ef /llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | |
| parent | f019e5f73ed732b374e376f5ddbba5d1f67dca0c (diff) | |
| download | llvm-b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc.zip llvm-b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc.tar.gz llvm-b241f3cb292d0ba1ad5a33b3bbd4a8a3a9c909dc.tar.bz2 | |
[LLDB] Use path relative to binary for finding .dwo files.
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.
Differential Revision: https://reviews.llvm.org/D97786
Diffstat (limited to 'llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp')
0 files changed, 0 insertions, 0 deletions