[llvm] [llvm-dwp] Add a new flag `--exec-dwo-path-remapping-file=<filename>`. (PR #157587)

[Michael Park via llvm-commits]

mpark wrote:

> > > Having to read a file seems a bit unfortunate - could we do something that matches existing debug info features like `-fdebug-prefix-map`?
> > 
> > 
> > Hi @dwblaikie, yes, good question. For our use case, the remapping is not from one directory to another but rather on a per-file basis, which is why this takes a file of mappings per file. This has to do with content-based hashes in output paths in Buck2. Specifically, under such a model the output path of an artifact is expected to include the hash of its contents, which of course can be different for every file within a directory.
> 
> OK, thanks for the context.
> 
> Hmm - one thing we don't do at Google/my use case - is build a DWP from an executable. We build a DWP from the same list of object files that were sent to the linker. (this means the DWP can be generated at the same time as the linked executable, rather than waiting for one to do the other - it does mean that linker-omitted object files still end up in the DWP, which is probably pretty unfortunate for DWP file size)
> 
> Is that an option for you? If you have a list of object files (in your mapping file) you could pass those to the dwp tool directly instead?

Right, we did try this approach but the resulting DWP file size was indeed too big for us. There's significant size difference from the linker dropping a bunch of DWOs in the executable.

> > It sounds like Bazel has this feature as well, maybe? Based on [Experimental Content-Based Output Paths](https://docs.google.com/document/d/17snvmic26-QdGuwVw55Gl0oOufw9sCVuOAvHqGZJFr4/edit?tab=t.0#heading=h.5mcn15i0e1ch). Do you know how this situation is handled there?
> 
> No idea, unfortunately.

Gotcha, thanks!

https://github.com/llvm/llvm-project/pull/157587