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

[Sterling Augustine via Phabricator via llvm-commits]

saugustine added a comment.

In D80168#2049569 <https://reviews.llvm.org/D80168#2049569>, @dblaikie wrote:

> Yeah, I'm kind of inclined to agree with @aprantl here - when the client asks for relative names I could see how that'd be reasonable to say "don't add the compilation dir" but I'm not sure what it means for other paths/doesn't necessarily seem reasonable for it to mean "give me back the unqualified name" even if it's relative to some other/unknown directory.
>
> How would the client then know where to find this name relative to?


The same way something finds the name relative in a compilation relative to -I/foo/bar. But I'm not terribly attached to this, so fine.

>> 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.
> 
> I /think/ I'd be open to special casing directory zero for this

This works fine for the deeper use case I have in mind, but unfortunately, for the test case under dwarf4, llvm uses a a full path for the include directory, and a plain filename for the file, so although it does actually behave the way you are specifying above, it doesn't actually test the relativenames part:

/usr/local/google/home/saugustine/llvm-new/llvm-project/llvm/test/tools/llvm-symbolizer

>> 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.
> 
> It seems like a client that ended up with this response would have to resolve all relative names relative to both the new compilation dir/root, and any include paths (which it can't determine from the DWARF at all) - that doesn't seem to me like a great state of affairs? But legit question what asking for relative names means. I think "relative to the compilation dir, but otherwise absolute" makes some sense - you have system directories at system-known locations, but your source tree might be moving around on different distributed build machines, etc. Everything relative to a variety of different directories seems difficult to work with in practice.



In D80168#2060753 <https://reviews.llvm.org/D80168#2060753>, @aprantl wrote:

> Why is it necessary to check in the binary? Could we just assemble the input with llvm-mc on the fly?


Because when you assemble with llvm-mc in the usual test suite, it sets the compilation directory, include directory, and input file like so:

comp_dir: location where llvm-mc is run.
include_dir: absolute path to relativenames.s in the source tree
filename: "relativenames.s"

So, after the comments above that we *don't* want the remove the include dir, even if it is an absolute path, the difference between the output with relative names and without is nothing: We still get the absolute path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80168