[PATCH] D36758: [LLD COFF / PDB] Incrementally update the BuildId when writing a PDB.

[Reid Kleckner via Phabricator via llvm-commits]

rnk added a comment.

In https://reviews.llvm.org/D36758#842357, @zturner wrote:

> In https://reviews.llvm.org/D36758#842342, @ruiu wrote:
>
> > I think it is more straightforward if you change Writer::writeBuildId to compute a hash using not only an executable but also a pdb file. If you do that, every time debug info is different, you'll get a different build id, which I think solves the issue.
> >
> > That way, we can still maintain build reproducibility. I don't want to use a random value as a build id.
>
>
> I actually think that would be rather difficult.  First we would have to emit the entire executable and PDB, then we would have to hash them, then we would have to modify them and write them again.
>
> Even if we did do it that way, there is another problem.  Now every time the debug info changes, a new PDB is generated, which means you get a new entry in your symbol cache / symbol server.  Over time, your symbol server will grow indefinitely in size because stale entries aren't overwritten, they are copied to a new location (it computes the folder to store the symbol file in based on the GUID).
>
> I realize this is not what any of us wants, but if we want to be compatible with MS symbol servers, I believe this is the way it has to be done.


This is also true. We have to try to reuse the PDB GUID if we can. This means our output is not a pure function of the input objects, unless you consider the output image as an additional input. Once we accept that this will be the default operating model, adding a random number isn't that big of a deal. We can always offer an escape hatch.


https://reviews.llvm.org/D36758