commit 7809ac6b9d6fa488a028346af702a1473b09b937
author Zachary Turner <zturner@google.com> Thu Oct 10 20:25:51 2019 +0000
committer Zachary Turner <zturner@google.com> Thu Oct 10 20:25:51 2019 +0000
tree de16e8709b80cff40a26b29f5bd185204d0d9922
parent acdb89e153e76b3ed3119c01b44a104f7a97f8a6

[PDB] Fix bug when using multiple PCH header objects with the same name.

A common pattern in Windows is to have all your precompiled headers
use an object named stdafx.obj.  If you've got a project with many
different static libs, you might use a separate PCH for each one of
these.

During the final link step, a file from A might reference the PCH
object from A, but it will have the same name (stdafx.obj) as any
other PCH from another project.  The only difference will be the
path.  For example, A might be A/stdafx.obj while B is B/stdafx.obj.

The existing algorithm checks only the filename that was passed on
the command line (or stored in archive), but this is insufficient in
the case where relative paths are used, because depending on the
command line object file / library order, it might find the wrong
PCH object first resulting in a signature mismatch.

The fix here is to simply check whether the absolute path of the
PCH object (which is stored in the input obj file for the file that
references the PCH) *ends with* the full relative path of whatever
is specified on the command line (or is in the archive).

Differential Revision: https://reviews.llvm.org/D66431

git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@374442 91177308-0d34-0410-b5e6-96231b3b80d8