[PATCH] D80833: [CodeView] Add full repro to LF_BUILDINFO record

[Leonardo Santagada via Phabricator via llvm-commits]

santagada added a comment.

In D80833#2069411 <https://reviews.llvm.org/D80833#2069411>, @aganea wrote:

> In D80833#2069246 <https://reviews.llvm.org/D80833#2069246>, @amccarth wrote:
>
>> Does the full path to the tool end up only in the object file, or does this make it all the way to the final executable or library?
>
> The `LF_BUILDINFO` records for each .OBJ are emitted as they are in the final .PDB.
>
>> Does embedding full paths affect distributed builds or build reproducibility?
>
> It does affect reproducibility for distributed builds, the contents of `LF_BUILDINFO` for a remotely-compiled .OBJ will be different in the final .PDB.
> In our case, compilation jobs can be executed locally or remotely, depending on how they are queued.
> For example,
>
> - If a local compilation, `C:\.nuget\llvm.10.0.0.2\bin\clang-cl.exe` would be stamped in the `LF_BUILDINFO` record.
> - If a remote compilation, `C:\Users\SomeUser\AppData\Local\Temp\.fbuild.tmp\worker\toolchain.130589cdf35aed3b\clang-cl.exe` would be stamped (the compiler executable is sent to the remote worker).
>
> But you've got a good point. We would need an way to force the remote compiler to stamp the local path (which is unique for all users). We've got a manual override if the compiler path referred by `LF_BUILDINFO` can't be found locally, but this is a bit annoying, see: https://liveplusplus.tech/docs/documentation.html#FASTBuild.
> It is better if the right information was there in the first place in the .OBJ. Could we do a remapping instead through VFS maybe? I'd like to avoid adding yet-a-new-flag to handle that.

I'm quite late into this ticket, but just to tell our solution, our distributed compilation system maps its own work directory to an I:\ drive and all our compiler/dependencies live inside the same folder, so locally something is in D:\dev\game\toolset\compiler\clang-cl.exe becomes I:\dev\game\toolset\compiler\clang-cl.exe then when copying the objects back the distribution system maps I:\ to D:\, which doesn't break the obj sizes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80833