[PATCH] D43002: Emit S_OBJNAME symbol in CodeView

[Zachary Turner via Phabricator via llvm-commits]

zturner added a comment.

In https://reviews.llvm.org/D43002#1000711, @dblaikie wrote:

> Does this need to be the name of an actual object file? Any idea how this should work in the case of LTO?
>
> For the .dwo file name, which must be the actual name of the final .dwo file (ie: intermediate IR 'object' file names are not relevant, only the final true object file because that's where the .dwo file comes from) this wasn't passed down through debug info metadata (because at the time the metadata's generated the final object file name is not known - that metadata might be merged, split, Thin merged, etc, before the final object is emitted) but through the MCOptions struct passed into LLVM's MC layer.


I tested with MSVC LTCG (their name for LTO) and here's the behavior it exhibits.

1. When compiling with LTCG and outputting `foo.obj`, the output file is not recognized as a COFF object file.  I believe this matches our behavior of outputting bitcode files.
2. When linking 2 LTCG object files together and getting a final PDB, the object name symbols reference the "pseudo-object files" mentioned in step 1.

I believe the reason for this behavior is that the final PDB contains information about every original compiland, regardless of whether it participated in LTO.  I mentioned in the original patch description that the `S_OBJNAME` symbol is 1 out of 2 symbols that we don't yet emit.  The other one emits more info including (among other things) the full command line used to generate the object file.  So I think the idea here is that with all of this information combined, given only a PDB a person can reproduce the exact build.  For that reason I think this needs to be the original bitcode-holding .o files.


https://reviews.llvm.org/D43002