[PATCH] D80168: For --relativenames, handle dwarf absolute include directories similarly to compilation directories.

[Sterling Augustine via Phabricator via llvm-commits]

saugustine marked 2 inline comments as done.
saugustine added inline comments.


================
Comment at: llvm/lib/DebugInfo/DWARF/DWARFDebugLine.cpp:1240
+      isPathAbsoluteOnWindowsOrPosix(IncludeDir)) {
+    Result = std::string(llvm::sys::path::filename(FileName));
+    return true;
----------------
aprantl wrote:
> It's not obvious to me how returning FileName is the right thing here as I'm unfamiliar with this code. Can you explain the mechanism a little?
Dwarf saves file names in three pieces:

Compilation directory (This is stored in the TU, and just implied as entry zero in the include directory list of the line table. Dwarf 5 makes it explicit in the directory list). It is an absolute path
Include Directory. This can be an absolute path and is referenced at the filename level with an index into the table.
File. In spite of the name, this could be a full path, a partial path, or just the filename.

The normal case to find the absolute path to a file is:

compilation directory + include directory + filename

But a producer could have stored the full path in include directory + filename, or just plain filename. Different producers can do different things, so whatever happens here will be a bit of a heuristic.

The immediate case is that if a file has an include directory of zero under dwarf 5, that is the same as the compilation directory, and it should not be added relative names. This allows for a consumer to set a single base directory for finding the files, even if the root has changed.

But more generally, if the producer chose to use an absolute path as the include directory, that probably means that the include directory was specified as an absolute path on the command line (at least not relative to the compilation directory). If, under relative names we return the filename as an absolute path here, the consumer can't specify a different root for this set of files without quite a bit more guesswork.

Hope this helps.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80168