[CodeView] Add full repro to LF_BUILDINFO record

[aganea]

Summary

This patch adds some missing information to the LF_BUILDINFO which allows for rebuilding a .CPP without any external dependency but the .OBJ itself (other than the compiler).

Some external tools that we are using (Recode, Live++) are extracting the information to reproduce a build without any knowledge of the build system. The LF_BUILDINFO therefore stores a full path to the compiler, the PWD, a relative or absolute path to the TU, and the full CC1 command line. The command line needs to be freestanding (not depend on any environment variables). In the same way, MSVC doesn't store the provided command-line, but an expanded version (somehow their equivalent of CC1) which is also freestanding.

For more information see PR36198 and D43002.

[akhuang]

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

940–941

Can the 'path to compiler and command line' part of the FIXME be removed?

[aganea]

As requested.

[hans]

clang/include/clang/Basic/CodeGenOptions.h

320 ↗

(On Diff #267331)

The name BuildTool makes me think of things like Make or MSBuild rather than the compiler. And in this case we know the compiler is Clang :-) Also since this is for capturing the cc1 arguments, it shouldn't really matter if it's clang-cl, clang++ or just clang. So it seems unfortunate that it has to be piped through all the way like this..

Is there some way we could just grab the path to the current clang binary during the pdb writing?

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

894

Don't we already have code somewhere that can do this quoting? E.g. the code that prints the cc1 args for "clang -v"?

[aganea]

clang/test/CodeGen/debug-info-codeview-buildinfo.c

4

Is there a way to launch an arbitrary program from lit? I started extracting the tool and the cmd-line from the .OBJ, to run it again. But I couldn't figure out how to start the extracted tool pathname? Something along the lines of

// RUN: eval $CMD

[aganea]

clang/include/clang/Basic/CodeGenOptions.h

320 ↗

(On Diff #267331)

There's sys::fs::getMainExecutable(const char *argv0, void *MainExecAddr) but that's not guaranteed to work on all platforms, you still need to provide argv[0] to fallback, see https://github.com/llvm/llvm-project/blob/master/llvm/lib/Support/Unix/Path.inc#L232
I'm not well versed in Unix distros, can this only rarely occur?
Would you prefer that I used that function instead? (it is ok on Windows though)

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

894

Yes, the code below was copy-pasted from Command::printArg. But that's in Clang. Should I make that code common somewhere in llvm/lib/Support?

[hans]

clang/include/clang/Basic/CodeGenOptions.h

320 ↗

(On Diff #267331)

I think it can occur for example if the compiler is running in a chroot. And probably other cases as well.
So maybe piping the path through is better. But perhaps we should just call it argv0?
Or could we get away with putting just "clang" there? Does the tool consuming this info actually need the real path to the compiler or could we rely on it finding it on PATH?

clang/test/CodeGen/debug-info-codeview-buildinfo.c

4

Hmm, I can't think of any way to do that with lit. But it's probably enough to check that the the data looks reasonable without actually invoking the tool again?

[amccarth]

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? Does embedding full paths affect distributed builds or build reproducibility?

[aganea]

In 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.

clang/include/clang/Basic/CodeGenOptions.h

320 ↗

(On Diff #267331)

Ok for argv0.
Users can have several versions of a toolchain installed locally, if they switch between branches or if working on different games at the same time.
We need to identify the right compiler through its full path, we can't rely on PATH.

[thakis]

The change description says something about PWD (which makes me worried about build determinism, like amccarth), but I don't see anything about that in the diff.

The diff as-is looks fine to me with hans's comment about duplication resolved in some form. Please don't add code that stores absolute paths, but at the moment this doesn't do that as far as I can tell :)

[amccarth]

In D80833#2069874, @thakis wrote:

The change description says something about PWD

I believe that was a typo for CWD.

Please don't add code that stores absolute paths, but at the moment this doesn't do that as far as I can tell :)

Ah, but the summary suggests that it is:

The LF_BUILDINFO therefore stores a full path to the compiler....

From what I see, it's storing Args[0], which is usually the program name as specified on the command line. If a build system is using full paths in the commands, I think they will be stored.

clang/test/CodeGen/debug-info-codeview-buildinfo.c

9

PWD? Did you mean CWD (current working directory)?

[aganea]

I didn't change the PWD/CWD stored in LF_BUILDINFO, it has already been done by Reid a while ago: D53179 (it already stores absolute paths)

However absolute paths are stored by design, if we want to reproduce the build locally. I can't see how this feature could be useful if we didn't store absolute paths. The user could have many different branches of the same game synced locally (we're using perforce).

We could somehow defer the full path calculation to link-time if we didn't want full paths in the .OBJs. But each LF_BUILDINFO in the final .PDB needs to store full local paths.
Please let me know what direction should be taken.

This is what I have now:

> cat b.cpp
int f() { return 42; }

# With Microsoft cl.exe (VS2019):

> cl b.cpp /c /Z7
> llvm-pdbutil dump -all b.obj | grep LF_BUILDINFO -A 5 -B 6
0x1007 | LF_STRING_ID [size = 248] ID: <no type>, String: -c -Z7 -MT -I"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\ATLMFC\include" -I"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include" -I"C:\Program
0x1008 | LF_STRING_ID [size = 268] ID: <no type>, String:  Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um"
0x1009 | LF_SUBSTR_LIST [size = 16]
         0x1007: `-c -Z7 -MT -I"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\ATLMFC\include" -I"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include" -I"C:\Program`
         0x1008: ` Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um"`
0x100A | LF_STRING_ID [size = 160] ID: 0x1009, String:  -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt" -TP -X
0x100B | LF_BUILDINFO [size = 28]
         0x1003: `D:\llvm-project`
         0x1004: `C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\bin\HostX64\x64\cl.exe`
         0x1005: `b.cpp`
         0x1006: `D:\llvm-project\vc140.pdb`
         0x100A: ` -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt" -TP -X`

# With Clang:

> clang-cl b.cpp /c /Z7
> llvm-pdbutil dump -all b.obj | grep LF_BUILDINFO -A 5
0x1007 | LF_BUILDINFO [size = 28]
         0x1003: `D:\llvm-project`
         0x1005: `D:\llvm-project\buildninjaDebMSVC\bin\clang-cl.exe`
         0x1004: `b.cpp`
         <no type>: ``
         0x1006: `-cc1 -triple x86_64-pc-windows-msvc19.26.28806 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -main-file-name -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fms-volatile -fdiagnostics-format msvc -gcodeview -debug-info-kind=limited -resource-dir "D:\llvm-project\buildninjaDebMSVC\lib\clang\11.0.0" -internal-isystem "D:\llvm-project\buildninjaDebMSVC\lib\clang\11.0.0\include" -internal-isystem "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\ATLMFC\include" -internal-isystem "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.26.28801\include" -internal-isystem "C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt" -fdeprecated-macro -fdebug-compilation-dir "D:\llvm-project" -ferror-limit 19 -fmessage-length=120 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.26.28806 -std=c++14 -fdelayed-template-parsing -fcolor-diagnostics -faddrsig -o b.obj -x c++ `

clang/test/CodeGen/debug-info-codeview-buildinfo.c

9

I meant the current working directory when the program starts. I was under the impression that the nomenclature for that is PWD = CWD at startup. While CWD is the current directory at any point in time during the execution, and can be different of PWD.
Would you prefer if I changed the regex capture name to CWD?

[hans]

In D80833#2071818, @aganea wrote:

I didn't change the PWD/CWD stored in LF_BUILDINFO, it has already been done by Reid a while ago: D53179 (it already stores absolute paths)

That's surprising to me. Nico is the real export on reproducible builds, but we generally try very hard to make builds reproducible independent of source and build dir. Maybe there should be a flag controlling this? /Brepro?

[thakis]

We don't store physical absolute paths in pdbs if you hold things right. Look for /pdbsourcepath: in http://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html . rnk's change seems to store the main TU's dir as cwd, which likely either takes the dir from the main TU as passed (ie if you pass an erlative path, it stores that), or it honors /pdbsourcepath:. If that's fine as-is, that's ok. It's different from what pwd returns though I think. (imagine you're in c:\foo and you build bar\baz.cc. the cwd in the pdb will be c:\foo\bar but the command will be relative to c:\foo if I understand things right? I might not though.)

[aganea]

• Using sys::flattenWindowsCommandLine instead of previous quoting function, as suggested by @hans
• Added Clang tests for -fdebug-compilation-dir .
• Added LLD support for making an absolute path out of LF_BUILDINFO's CurrentDirectory.

[aganea]

In D80833#2071863, @hans wrote:

In D80833#2071818, @aganea wrote:

I didn't change the PWD/CWD stored in LF_BUILDINFO, it has already been done by Reid a while ago: D53179 (it already stores absolute paths)

That's surprising to me. Nico is the real export on reproducible builds, but we generally try very hard to make builds reproducible independent of source and build dir. Maybe there should be a flag controlling this? /Brepro?

Ah, you must be using -fdebug-compilation-dir on Chromium I suppose, to make paths relative in .OBJs. Otherwise the default is the full path to PWD/CWD. Added a test for that.

In D80833#2071969, @thakis wrote:

We don't store physical absolute paths in pdbs if you hold things right. Look for /pdbsourcepath: in http://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html . rnk's change seems to store the main TU's dir as cwd, which likely either takes the dir from the main TU as passed (ie if you pass an erlative path, it stores that), or it honors /pdbsourcepath:. If that's fine as-is, that's ok. It's different from what pwd returns though I think. (imagine you're in c:\foo and you build bar\baz.cc. the cwd in the pdb will be c:\foo\bar but the command will be relative to c:\foo if I understand things right? I might not though.)

Without -fdebug-compilation-dir, the full path is stored in LF_BUILDINFO (see CodeGenOpts::DebugCompilationDir and CGDebugInfo::getCurrentDirname())
With -fdebug-compilation-dir ., the PWD/CWD becomes relative ('.') and I've added code in LLD to call pdbMakeAbsolute on it, like for other PDB strings.
Now /pdbsourcepath works as well (all this is covered in lld/test/COFF/pdb-relative-source-lines.test).
However if you're in c:\foo and you do clang-cl /c bar\baz.cc, then bar\baz.cc will be stored as-it-is in LF_BUILDINFO (the PWD/CWD and the main filename are stored separately)

The only absolute paths that remain are: a. the compiler path (D:\llvm-project\buildninjaDebMSVC\bin\clang-cl.exe in the yaml below) and b. the -internal-isystem paths. However that is not an issue on our end, as we're building with -nostdinc + nuget packages installed in a fixed dir on all users' machines. Not sure how that works for you?

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

894

Replaced by llvm::sys::flattenWindowsCommandLine. I can't find any equivalent for Linux, I hope just aggregating the arguments with spaces in between is fine?

[hans]

The only absolute paths that remain are: a. the compiler path (D:\llvm-project\buildninjaDebMSVC\bin\clang-cl.exe in the yaml below) and b. the -internal-isystem paths. However that is not an issue on our end, as we're building with -nostdinc + nuget packages installed in a fixed dir on all users' machines. Not sure how that works for you?

a. The compiler path is only absolute because it was absolute when put into argv[0] right? I don't see anything in the code that makes it absolute? I imagine most build systems will invoke the compiler using an absolute path so you'll get the desired result.

b. We pass -imsvc flags to specify relative paths to the msvc headers, so the -internal-isystem paths passed to cc1 are relative too.

clang/test/CodeGen/debug-info-codeview-buildinfo.c

2

The %s arg needs to come after "--", otherwise it can be interpreted as a command line flag, e.g. on Mac files are often under /Users which will be interpreted as a /U flag (see other tests using %clang_cl for examples).

clang/tools/driver/cc1_main.cpp

184 ↗

(On Diff #268359)

Maybe I'm missing something, but why is this changing? The current code with Argv0 and the rest of the args as separate parameters seems like it would fit in will with the rest of the patch?

lld/COFF/PDB.cpp

1041 ↗

(On Diff #268359)

Naive question because I'm not familiar with the PDB writing, but would it be possible to remap the LF_BUILDINFO entries earlier, e.g. when they're read in from the object files? It seems like a lot of code is now added to do the remapping "after the fact".

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

898

Does Arg.data() == nullptr really happen here?

904

I suppose this won't work with filenames that contain spaces.

I was hoping we could do whatever "clang -v" does when it prints arguments. It seems to do some basic quoting and escaping. Does it have some function we could call from here?

941–950

Wouldn't it be simpler to just check Argv0 != nullptr here?

[aganea]

Addressed comments (see inline). Ensured the generated .OBJ contains relative paths when passing -fdebug-compilation-dir . -no-canonical-prefixes.

[aganea]

In D80833#2073458, @hans wrote:

a. The compiler path is only absolute because it was absolute when put into argv[0] right? I don't see anything in the code that makes it absolute? I imagine most build systems will invoke the compiler using an absolute path so you'll get the desired result.

Understood, I wasn't using -no-canonical-prefixes that's why I was seeing full paths for argv[0].

clang/test/CodeGen/debug-info-codeview-buildinfo.c

2

Fixed, Reid already mentionned that a while ago, I'll remember next time!

clang/tools/driver/cc1_main.cpp

184 ↗

(On Diff #268359)

Reverted.

lld/COFF/PDB.cpp

1041 ↗

(On Diff #268359)

The whole type merging machinery isn't designed for changing records on-the-fly. We only modify TypeIndex values inside the record, but for that we have hardcoded offsets (all the discoverTypeIndices functions in https://github.com/llvm/llvm-project/blob/cda7ff9ddcefe0051d173e7c126c679063d29fbb/llvm/lib/DebugInfo/CodeView/TypeIndexDiscovery.cpp). The rest of the record is emitted as-it-is in the output TPI or IPI streams.

It's certainly feaseable to modify records in TypeStreamMerger in the same way we examine the LF_ENDPRECOMP record. However that requires a lot more piping, and I figured it wasn't worth it (unless we have other record types to modify in the future).

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

898

Yes if passing clang -cc1 directly. Both the CC1Command and InitLLVM are pushing a nullptr terminator as the last arg :-( This seems quite widespead behavior across the codebase.

904

The code for printing "clang -v" is/was entirely in Clang: https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/Job.cpp#L103

I've moved Command::printArg to llvm::sys::printArg and using that now.
This creates a slight difference from MSVC, in the sense that with Clang all arguments are quoted, no matter what. Whereas MSVC adds quotes when it's necessary (that's LLVM's sys::flattenWindowsCommandLine behavior). But I think that shouldn't matter much.

Please @stefan_reinalter @lantictac let me know if you think otherwise.

D:\llvm-project> buildninjaRel\bin\clang-cl /c b.cpp /Z7 -fdebug-compilation-dir . -no-canonical-prefixes
D:\llvm-project> buildninjaRel\bin\llvm-pdbutil.exe dump -all b.obj | grep LF_BUILDINFO -A 5
0x1007 | LF_BUILDINFO [size = 28]
         0x1003: `.`
         0x1005: `buildninjaRel\bin\clang-cl.exe`
         0x1004: `b.cpp`
         <no type>: ``
         0x1006: `"-cc1" "-triple" "x86_64-pc-windows-msvc19.26.28806" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-main-file-name" "b.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mframe-pointer=none" "-relaxed-aliasing" "-fmath-errno" "-fno-rounding-math" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" "-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" "-fms-volatile" "-fdiagnostics-format" "msvc" "-gcodeview" "-debug-info-kind=limited" "-resource-dir" "buildninjaRel\\lib\\clang\\11.0.0" "-internal-isystem" "buildninjaRel\\lib\\clang\\11.0.0\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\VC\\Tools\\MSVC\\14.26.28801\\ATLMFC\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\VC\\Tools\\MSVC\\14.26.28801\\include" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.8\\include\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\ucrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\shared" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\winrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\cppwinrt" "-fdeprecated-macro" "-fdebug-compilation-dir" "." "-ferror-limit" "19" "-fmessage-length=146" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.26.28806" "-std=c++14" "-fdelayed-template-parsing" "-fcolor-diagnostics" "-faddrsig" "-x" "c++"`

[aganea]

Fix tests.

[hans]

lgtm

clang/test/CodeGen/debug-info-codeview-buildinfo.c

4

This one also needs "-- %s" at the end.

[amccarth]

My only real concern was about the possible reproducibility impact of introducing absolute paths into the binaries. If @thakis and @hans are satisfied this is OK, then LGTM.

clang/test/CodeGen/debug-info-codeview-buildinfo.c

9

Sorry, I always misread "pwd" as "password."

[aganea]

Thanks for taking the time @hans, @amccarth!

I've split this into several smaller patches, to ease bisect if needs be:
rGa45409d8855a1e4538990507ef25e9b51c090193 - [Clang] Move clang::Job::printArg to llvm::sys::printArg. NFCI.
rG24eff42ba4b85eaa5429e8efe9bd2070d34ba1f7 - [CodeView] Add TypeCollection::replaceType to replace type records post-merging
rG89ea0b05207d45c145fb525df554b3b986ae379b - [MC] Pass down argv0 & cc1 cmd-line to the back-end and store in MCTargetOptions
rG403f9537924b8910ed4f741ed96c61f5e657915b - [CodeView] Add full repro to LF_BUILDINFO record <- this enables the feature

I've supplemented this current patch with two fixes:
rG8374bf43634725dc02a262a77b5f940fca25938c - [CodeView] Fix generated command-line expansion in LF_BUILDINFO. Fix the 'pdb' entry which was previously a null reference, now an empty string.
rGcab3fc53d2e173243a462e9c8e914af58ddbeaba - Fix linker error in clang-fuzzer following 89ea0b05207d45c145fb525df554b3b986ae379b

[thakis]

Looks like this breaks tests on mac: http://45.33.8.238/mac/15751/step_10.txt

Please take a look.

[aganea]

In D80833#2101057, @thakis wrote:

Looks like this breaks tests on mac: http://45.33.8.238/mac/15751/step_10.txt

Please take a look.

Checking now.

[thakis]

Failing on Windows too, actually: http://45.33.8.238/win/17931/step_10.txt

[thakis]

This is still broken; bots have been red for a few hours now. Can we revert and analyze async, to keep the bots green please?

[aganea]

In D80833#2101636, @thakis wrote:

This is still broken; bots have been red for a few hours now. Can we revert and analyze async, to keep the bots green please?

Yes I will revert, but I don't understand. All the tests pass here on four different machines, Windows and Linux, when compiling with different compilers and different configurations. I will investigate offline.

[thakis]

Hm http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/16533 is happy so it's not broken on all Windows machines. Guess I'll take a look on what's going on. You can hold off on the revert for now.

[aganea]

In D80833#2101690, @thakis wrote:

Hm http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/16533 is happy so it's not broken on all Windows machines. Guess I'll take a look on what's going on. You can hold off on the revert for now.

I wonder if the "sed" substitution below could fail on some machines? (see lld/test/COFF/pdb-relative-source-lines.test)

[aganea]

Reverted in rG2ae0df5be7408a79524743762b6c74953f31b805. I'll investigate the issue on my end.

[thakis]

I took a look. It consistently fails for me on mac and on Windows in a git bash shell, but it passes in cmd with unxutils. Maybe this needs something like eac56724fd955af0f8521557cacc57a83f371649 ?

[aganea]

clang/test/CodeGen/debug-info-codeview-buildinfo.c

5

Line 4 here fails on s390x but not on other Unix flavors, see: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/33346/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-info-codeview-buildinfo.c

@thakis @uweigand Any ideas would could go wrong here?

lld/test/COFF/pdb-relative-source-lines2.test

44 ↗

(On Diff #272556)

@thakis : I was unable to make this work otherwise than by restricting this test to windows (REQUIRES: system-windows at the top). This works now on Cygwin (git bash) and GnuWin32, but not on Linux. Would you mind if this test was Windows-specific?

[uweigand]

Line 4 here fails on s390x but not on other Unix flavors, see: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/33346/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-info-codeview-buildinfo.c

@thakis @uweigand Any ideas would could go wrong here?

Well, when I try it, the compile command is creating a native format object file, in this case a 64-bit big-endian s390x ELF file, and that format is not recognized by llvm-pdbutil. Not sure why this wouldn't fail the same way on any other non-Windows target, though.

I guess it should work if you pass the appropriate --target option to the compiler to force creation of a Windows object file.

[aganea]

In D80833#2108423, @uweigand wrote:

Line 4 here fails on s390x but not on other Unix flavors, see: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/33346/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-info-codeview-buildinfo.c

@thakis @uweigand Any ideas would could go wrong here?

Well, when I try it, the compile command is creating a native format object file, in this case a 64-bit big-endian s390x ELF file, and that format is not recognized by llvm-pdbutil. Not sure why this wouldn't fail the same way on any other non-Windows target, though.

I guess it should work if you pass the appropriate --target option to the compiler to force creation of a Windows object file.

Thanks for getting back! That was my suspicion. I initially thought that using clang-cl would automatically target windows-msvc, but it seems that's not the case, I'll add it.

[aganea]

When using clang-cl, this code should set it to the right format, on any platform: https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/Driver.cpp#L1071
However maybe something else happens on big endian architectures?

@uweigand Would you mind running the first clang-cl command with -### see what target is being used? This is what I'm seeing on my Ubuntu machine. Note the x86_64-pc-windows-msvc19.11.0 triple. If using plain clang -c b.cpp then x86_64-unknown-linux-gnu is used instead.

aganea@PC:/mnt/f/llvm-project$ cat b.cpp
int A;
int foo() {
  return A * 20;
}
int main() {
  return foo();
}
aganea@PC:/mnt/f/llvm-project$ ./buildclang9/bin/clang-cl /c b.cpp -###
clang version 11.0.0 (https://github.com/llvm/llvm-project.git bfdb834bc3d5e948002e5061a4c50d5c9a97de59)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: /mnt/f/llvm-project/./buildclang9/bin
 (in-process)
 "/mnt/f/llvm-project/buildclang9/bin/clang-11" "-cc1" "-triple" "x86_64-pc-windows-msvc19.11.0" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-main-file-name" "b.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mframe-pointer=none" "-relaxed-aliasing" "-fmath-errno" "-fno-rounding-math" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" "-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" "-fms-volatile" "-fdiagnostics-format" "msvc" "-dwarf-column-info" "-resource-dir" "/mnt/f/llvm-project/buildclang9/lib/clang/11.0.0" "-internal-isystem" "/mnt/f/llvm-project/buildclang9/lib/clang/11.0.0/include" "-fdeprecated-macro" "-fdebug-compilation-dir" "/mnt/f/llvm-project" "-ferror-limit" "19" "-fmessage-length" "0" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.11" "-std=c++14" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-faddrsig" "-o" "b.obj" "-x" "c++" "b.cpp"

[uweigand]

Hmm, with clang-cl it seems the driver is trying to use this:
Target: s390x-pc-windows-msvc
which of course doesn't exist. Not sure what is supposed to be happening here, but it seems that it's falling back on s390x-linux since on s390x, Linux is currently the only supported OS.

[aganea]

In D80833#2109172, @uweigand wrote:

Hmm, with clang-cl it seems the driver is trying to use this:
Target: s390x-pc-windows-msvc
which of course doesn't exist. Not sure what is supposed to be happening here, but it seems that it's falling back on s390x-linux since on s390x, Linux is currently the only supported OS.

I'm seeing some of the tests are setting the target explicitly %clang_cl --target=x86_64-windows-msvc. Would that work on your machine? Or should I do UNSUPPORTED: s390x ?

[uweigand]

In D80833#2123508, @aganea wrote:

In D80833#2109172, @uweigand wrote:

Hmm, with clang-cl it seems the driver is trying to use this:
Target: s390x-pc-windows-msvc
which of course doesn't exist. Not sure what is supposed to be happening here, but it seems that it's falling back on s390x-linux since on s390x, Linux is currently the only supported OS.

I'm seeing some of the tests are setting the target explicitly %clang_cl --target=x86_64-windows-msvc. Would that work on your machine? Or should I do UNSUPPORTED: s390x ?

Sorry, looks like I missed this. I think using an explicit target should work.

[aeubanks]

This seems to be breaking determinism on Windows builds, see https://crbug.com/1117026. Can this be reverted and fixed?

[aganea]

In D80833#2221866, @aeubanks wrote:

This seems to be breaking determinism on Windows builds, see https://crbug.com/1117026. Can this be reverted and fixed?

Will do.

[santagada]

In D80833#2069411, @aganea wrote:

In 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.

[dexonsmith]

In D80833#2069411, @aganea wrote:

In D80833#2069246, @amccarth wrote:

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.

I don't think the path to the compiler is the only concern regarding reproducible builds. Including the full command-line means that artifacts change when options that have no (other) effect on the output are added. E.g., adding -Wall will create a different object file than -Wmost. I worry this is the wrong direction for default clang behaviour.

Should this new instability be restricted to when users explicitly request it?

[dexonsmith]

If you do go with "off-by-default", the natural driver option to use would be the existing -grecord-command-line. You could use the same plumbing through -cc1 that it does.

[aganea]

In D80833#3052551, @dexonsmith wrote:

In D80833#2069411, @aganea wrote:

In D80833#2069246, @amccarth wrote:

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.

I don't think the path to the compiler is the only concern regarding reproducible builds. Including the full command-line means that artifacts change when options that have no (other) effect on the output are added. E.g., adding -Wall will create a different object file than -Wmost. I worry this is the wrong direction for default clang behaviour.

In my sense, the fact that an option doesn't change the output is orthogonal to producing a deterministic output. I think most caching systems treat the compiler as a black box, by simply hashing the command-line and assuming the same .OBJ will be generated from that command-line. The build system could filter out options that are known to have no effect on the output, to address your concern. But I feel this is outside of the scope of this patch?

Should this new instability be restricted to when users explicitly request it?

The goal of this patch (and D43002) is simply to be on-par with what MSVC generates by default. It seems a bit counter-intuitive to provide -grecord-command-line to clang-cl only to match the MSVC behavior, but if that's the general consensus, I'm fine as long as LF_BUILDINFO is supported in LLVM.

In D80833#3052741, @dexonsmith wrote:

If you do go with "off-by-default", the natural driver option to use would be the existing -grecord-command-line. You could use the same plumbing through -cc1 that it does.

You mean using the llvm.commandline metadata? That's an interesting idea which should be explored.

[aganea]

Rebase & simplify.

[aganea]

@dexonsmith The issue with -grecord-command-line/-frecord-command-line is that it isn't producing a self-standing command-line. For example:

> clang-cl /c main.cpp /clang:-grecord-command-line /Z7

would record: d:\\git\\llvm-project\\stage1\\bin\\clang-cl.exe --driver-mode=cl -c main.cpp /clang:-grecord-command-line /Z7 -grecord-command-line

Whereas our patch records the cc1 command, which is self-standing:

> stage1\bin\clang-cl /c main.cpp /Z7 -no-canonical-prefixes -fdebug-compilation-dir=.
> stage1\bin\llvm-pdbutil.exe dump -types .\main.obj | grep -A5 LF_BUILDINFO
0x1008 | LF_BUILDINFO [size = 28]
         0x1003: `.`
         0x1006: `stage1\bin\clang-cl.exe`
         0x1004: `main.cpp`
         0x1005: ``
         0x1007: `"-cc1" "-fmessage-length=120" "-fdiagnostics-format" "msvc" "-ferror-limit" "19" "-fcolor-diagnostics" "-mllvm" "-x86-asm-syntax=intel" "-disable-free" "-emit-obj" "-x" "c++" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-triple" "x86_64-pc-windows-msvc19.29.30138" "-resource-dir" "stage1\\lib\\clang\\14.0.0" "-isystem" "stage1\\lib\\clang\\14.0.0\\include" "-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\include" "-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.29.30133\\atlmfc\\include" "-isystem" "C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\ucrt" "-isystem" "C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\shared" "-isystem" "C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\um" "-isystem" "C:\\Scoop\\global\\apps\\winsdk\\10.0.22000.194\\sdk\\Include\\10.0.22000.0\\winrt" "-std=c++14" "-fmath-errno" "-fms-compatibility" "-fdelayed-template-parsing" "-pic-level" "2" "-stack-protector" "2" "-fvisibility" "default" "-fdeprecated-macro" "-fms-compatibility-version=19.29.30138" "-ffp-contract=on" "-fno-experimental-relative-c++-abi-vtables" "-O0" "-fdebug-compilation-dir=." "-fcoverage-compilation-dir=D:\\git\\llvm-project" "-faddrsig" "-fms-volatile" "-fno-use-cxa-atexit" "-gcodeview" "-gno-column-info" "-mrelax-all" "-mincremental-linker-compatible" "--mrelax-relocations" "-relaxed-aliasing" "-funwind-tables=2" "-mconstructor-aliases" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-flto-visibility-public-std" "-clear-ast-before-backend" "-debug-info-kind=constructor" "-fdiagnostics-hotness-threshold=0" "-D" "_MT"`

(the LF_BUILDINFO record is replicated unchanged in the .PDB)

Microsoft does something similair:

> cl /c /Z7 .\main.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30136 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.cpp
> llvm-pdbutil.exe dump -types .\main.obj | grep -B4 -A5 LF_BUILDINFO
0x1009 | LF_SUBSTR_LIST [size = 16]
         0x1007: `-c -Z7 -MT -IC:\Scoop\global\apps\vs_buildtools\16.11.5\VS\VC\Tools\MSVC\14.29.30133\ATLMFC\include -IC:\Scoop\global\apps\vs_buildtools\16.11.5\VS\VC\Tools\MSVC\14.29.30133\include -IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\ucrt`
         0x1008: ` -IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\shared -IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\um -IC:\Scoop\global\apps\winsdk\10.0.22000.194\sdk\include\10.0.22000.0\winrt -IC:\Scoop\global\apps\winsdk\10`
0x100A | LF_STRING_ID [size = 64] ID: 0x1009, String: .0.22000.194\sdk\include\10.0.22000.0\cppwinrt -TP -X
0x100B | LF_BUILDINFO [size = 28]
         0x1003: `D:\git\llvm-project`
         0x1004: `C:\Scoop\global\apps\vs_buildtools\16.11.5\VS\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.exe`
         0x1005: `.\main.cpp`
         0x1006: `D:\git\llvm-project\vc140.pdb`
         0x100A: `.0.22000.194\sdk\include\10.0.22000.0\cppwinrt -TP -X`

MSVC splits the command over multiple string records, I suppose to increase the chances of de-duplication in the .PDB, something that we could do later. But the essence is that the command is free-standing (note -X and the explicit includes) and can be run without any env.vars set, unlike -dwarf-debug-flags or -record-command-line.

clang/cmake/caches/BaremetalARM.cmake

 set(LLVM_TOOLCHAIN_TOOLS
   dsymutil
   llc
   llvm-ar
   llvm-cxxfilt
   llvm-dwarfdump
   llvm-nm
   llvm-objdump
+  llvm-pdbutil
   llvm-ranlib
   llvm-readobj
   llvm-size
   llvm-symbolizer
   opt
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS

clang/cmake/caches/CrossWinToARMLinux.cmake

 set(LLVM_TOOLCHAIN_TOOLS
   llvm-ar
   llvm-cov
   llvm-cxxfilt
   llvm-dwarfdump
   llvm-lib
   llvm-nm
   llvm-objdump
+  llvm-pdbutil
   llvm-profdata
   llvm-ranlib
   llvm-readobj
   llvm-size
   llvm-symbolizer
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS
   clang
   lld
   LTO
   clang-format
   builtins
   runtimes
   ${LLVM_TOOLCHAIN_TOOLS}
   CACHE STRING "")

clang/cmake/caches/Fuchsia-stage2.cmake

set(LLVM_TOOLCHAIN_TOOLS
   llvm-lib
   llvm-libtool-darwin
   llvm-lipo
   llvm-mt
   llvm-nm
   llvm-objcopy
   llvm-objdump
   llvm-otool
+  llvm-pdbutil
   llvm-profdata
   llvm-rc
   llvm-ranlib
   llvm-readelf
   llvm-readobj
   llvm-size
   llvm-strip
   llvm-symbolizer

clang/test/CodeGen/debug-info-codeview-buildinfo.c

+// REQUIRES: x86-registered-target
+// RUN: %clang_cl --target=i686-windows-msvc /c /Z7 /Fo%t.obj -- %s
+// RUN: llvm-pdbutil dump --types %t.obj | FileCheck %s
+// RUN: %clang_cl --target=i686-windows-msvc /c /Z7 /Fo%t.obj -fdebug-compilation-dir=. -- %s
+// RUN: llvm-pdbutil dump --types %t.obj | FileCheck %s --check-prefix RELATIVE
+
+int main() { return 42; }
+
+// CHECK:                       Types (.debug$T)
+// CHECK: ============================================================
+// CHECK: 0x[[PWD:.+]] | LF_STRING_ID [size = {{.+}}] ID: <no type>, String: [[PWDVAL:.+]]
+// CHECK: 0x[[FILEPATH:.+]] | LF_STRING_ID [size = {{.+}}] ID: <no type>, String: [[FILEPATHVAL:.+[\\/]debug-info-codeview-buildinfo.c]]
+// CHECK: 0x[[ZIPDB:.+]] | LF_STRING_ID [size = {{.+}}] ID: <no type>, String:
+// CHECK: 0x[[TOOL:.+]] | LF_STRING_ID [size = {{.+}}] ID: <no type>, String: [[TOOLVAL:.+[\\/]clang.*]]
+// CHECK: 0x[[CMDLINE:.+]] | LF_STRING_ID [size = {{.+}}] ID: <no type>, String: "-cc1
+// CHECK: 0x{{.+}} | LF_BUILDINFO [size = {{.+}}]
+// CHECK:          0x[[PWD]]: `[[PWDVAL]]`
+// CHECK:          0x[[TOOL]]: `[[TOOLVAL]]`
+// CHECK:          0x[[FILEPATH]]: `[[FILEPATHVAL]]`
+// CHECK:          0x[[ZIPDB]]: ``
+// CHECK:          0x[[CMDLINE]]: `"-cc1
+
+// RELATIVE:                       Types (.debug$T)
+// RELATIVE: ============================================================
+// RELATIVE: 0x{{.+}} | LF_BUILDINFO [size = {{.+}}]
+// RELATIVE:          0x{{.+}}: `.`

lld/test/COFF/Inputs/pdb_lines_1_relative.yaml

sections:
   - Name:            .data
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ, IMAGE_SCN_MEM_WRITE ]
     Alignment:       4
     SectionData:     ''
   - Name:            .bss
     Characteristics: [ IMAGE_SCN_CNT_UNINITIALIZED_DATA, IMAGE_SCN_MEM_READ, IMAGE_SCN_MEM_WRITE ]
     Alignment:       4
     SectionData:     ''
+    SizeOfRawData:   0
   - Name:            .xdata
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
     Alignment:       4
     SectionData:     '0104010004420000'
   - Name:            .text
     Characteristics: [ IMAGE_SCN_CNT_CODE, IMAGE_SCN_LNK_COMDAT, IMAGE_SCN_MEM_EXECUTE, IMAGE_SCN_MEM_READ ]
     Alignment:       16
     SectionData:     4883EC28E800000000904883C428C3
     Relocations:
       - VirtualAddress:  5
         SymbolName:      bar
         Type:            IMAGE_REL_AMD64_REL32
   - Name:            .drectve
     Characteristics: [ IMAGE_SCN_LNK_INFO, IMAGE_SCN_LNK_REMOVE ]
     Alignment:       1
     SectionData:     202F44454641554C544C49423A6C6962636D742E6C6962202F44454641554C544C49423A6F6C646E616D65732E6C6962
   - Name:            '.debug$S'
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
     Alignment:       4
-    SectionData:     04000000F10000002F0000002D003C1100000000D0000700000000000000581B000000000000636C616E672076657273696F6E20372E302E30200000F1000000300000002A0047110000000000000000000000001B000000000000000000000002100000000000000000006D61696E0002004F11F20000003000000000000000000000001B00000000000000030000002400000000000000020000000C000000030000001100000004000000F400000030000000010000001001EA6429BCE282CCF3F0E3CD93B216EB410000110000001001061EB73ABB642532857A4F1D9CBAC3230000F30000001C000000002E5C7064625F6C696E65735F312E63002E5C666F6F2E6800000000
     Subsections:
       - !Symbols
         Records:
           - Kind:            S_COMPILE3
             Compile3Sym:
               Flags:           [  ]
               Machine:         X64
-              FrontendMajor:   7
+              FrontendMajor:   11
               FrontendMinor:   0
               FrontendBuild:   0
               FrontendQFE:     0
-              BackendMajor:    7000
+              BackendMajor:    11000
               BackendMinor:    0
               BackendBuild:    0
               BackendQFE:      0
-              Version:         'clang version 7.0.0 '
+              Version:         'clang version 11.0.0 (https://github.com/llvm/llvm-project.git 77dad72eae974338ddc13d74783c012ccbb8c5ac)'
       - !Symbols
         Records:
           - Kind:            S_GPROC32_ID
             ProcSym:
               CodeSize:        27
               DbgStart:        0
               DbgEnd:          0
               FunctionType:    4098
               Flags:           [  ]
               DisplayName:     main
+          - Kind:            S_FRAMEPROC
+            FrameProcSym:
+              TotalFrameBytes: 40
+              PaddingFrameBytes: 0
+              OffsetToPadding: 0
+              BytesOfCalleeSavedRegisters: 0
+              OffsetOfExceptionHandler: 0
+              SectionIdOfExceptionHandler: 0
+              Flags:           [  ]
           - Kind:            S_PROC_ID_END
-            ScopeEndSym:
+            ScopeEndSym:     {}
       - !Lines
         CodeSize:        27
         Flags:           [  ]
         RelocOffset:     0
         RelocSegment:    0
         Blocks:
           - FileName:        '.\pdb_lines_1.c'
             Lines:
               - Offset:          0
                 LineStart:       2
                 IsStatement:     false
                 EndDelta:        0
               - Offset:          12
                 LineStart:       3
                 IsStatement:     false
                 EndDelta:        0
               - Offset:          17
                 LineStart:       4
                 IsStatement:     false
                 EndDelta:        0
-            Columns:
+            Columns:         []
       - !FileChecksums
         Checksums:
           - FileName:        '.\pdb_lines_1.c'
             Kind:            MD5
-            Checksum:        EA6429BCE282CCF3F0E3CD93B216EB41
+            Checksum:        9A64DD4298487888B1D99F825D520C5E
           - FileName:        '.\foo.h'
             Kind:            MD5
-            Checksum:        061EB73ABB642532857A4F1D9CBAC323
+            Checksum:        A9D05E6DC184DE20A57797E24F8B0E97
       - !StringTable
         Strings:
           - '.\pdb_lines_1.c'
           - '.\foo.h'
           - ''
           - ''
           - ''
+      - !Symbols
+        Records:
+          - Kind:            S_BUILDINFO
+            BuildInfoSym:
+              BuildId:         4105
     Relocations:
-      - VirtualAddress:  100
+      - VirtualAddress:  184
         SymbolName:      main
         Type:            IMAGE_REL_AMD64_SECREL
-      - VirtualAddress:  104
+      - VirtualAddress:  188
         SymbolName:      main
         Type:            IMAGE_REL_AMD64_SECTION
-      - VirtualAddress:  124
+      - VirtualAddress:  240
         SymbolName:      main
         Type:            IMAGE_REL_AMD64_SECREL
-      - VirtualAddress:  128
+      - VirtualAddress:  244
         SymbolName:      main
         Type:            IMAGE_REL_AMD64_SECTION
   - Name:            '.debug$T'
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
     Alignment:       4
-    SectionData:     0400000006000112000000000E0008107400000000000000001000001200011600000000011000006D61696E00F3F2F10E0008100300000000000000001000000E0001160000000003100000666F6F00
     Types:
       - Kind:            LF_ARGLIST
         ArgList:
           ArgIndices:      [  ]
       - Kind:            LF_PROCEDURE
         Procedure:
           ReturnType:      116
           CallConv:        NearC
Types:
           Options:         [ None ]
           ParameterCount:  0
           ArgumentList:    4096
       - Kind:            LF_FUNC_ID
         FuncId:
           ParentScope:     0
           FunctionType:    4099
           Name:            foo
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          .
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          pdb_lines_1.c
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          'buildninjaRel\bin\clang-cl.exe'
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          '"-cc1" "-triple" "x86_64-pc-windows-msvc19.26.28806" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-main-file-name" "pdb_lines_1.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mframe-pointer=none" "-relaxed-aliasing" "-fmath-errno" "-fno-rounding-math" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" "-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" "-fms-volatile" "-fdiagnostics-format" "msvc" "-gcodeview" "-debug-info-kind=limited" "-resource-dir" "D:\\llvm-project\\buildninjaRel\\lib\\clang\\11.0.0" "-internal-isystem" "D:\\llvm-project\\buildninjaRel\\lib\\clang\\11.0.0\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\VC\\Tools\\MSVC\\14.26.28801\\ATLMFC\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\VC\\Tools\\MSVC\\14.26.28801\\include" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.8\\include\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\ucrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\shared" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\winrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\cppwinrt" "-fdebug-compilation-dir" "." "-ferror-limit" "19" "-fmessage-length=146" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.26.28806" "-fdelayed-template-parsing" "-fcolor-diagnostics" "-faddrsig" "-x" "c"'
+      - Kind:            LF_BUILDINFO
+        BuildInfo:
+          ArgIndices:      [ 4101, 4103, 4102, 0, 4104 ]
   - Name:            .pdata
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ ]
     Alignment:       4
     SectionData:     000000001B00000000000000
     Relocations:
       - VirtualAddress:  0
         SymbolName:      main
         Type:            IMAGE_REL_AMD64_ADDR32NB
       - VirtualAddress:  4
         SymbolName:      main
         Type:            IMAGE_REL_AMD64_ADDR32NB
       - VirtualAddress:  8
-        SymbolName:      .xdata
+        SymbolTableIndex: 6
         Type:            IMAGE_REL_AMD64_ADDR32NB
+  - Name:            .llvm_addrsig
+    Characteristics: [ IMAGE_SCN_LNK_REMOVE ]
+    Alignment:       1
+    SectionData:     0A1D
   - Name:            .xdata
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_LNK_COMDAT, IMAGE_SCN_MEM_READ ]
     Alignment:       4
     SectionData:     '0104010004420000'
   - Name:            '.debug$S'
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_LNK_COMDAT, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
     Alignment:       4
-    SectionData:     04000000F10000002F000000290047110000000000000000000000000F00000000000000000000000410000000000000000000666F6F0002004F1100F20000003000000000000000000000000F000000180000000300000024000000000000000200000004000000030000000900000004000000
     Subsections:
       - !Symbols
         Records:
           - Kind:            S_GPROC32_ID
             ProcSym:
               CodeSize:        15
               DbgStart:        0
               DbgEnd:          0
               FunctionType:    4100
               Flags:           [  ]
               DisplayName:     foo
+          - Kind:            S_FRAMEPROC
+            FrameProcSym:
+              TotalFrameBytes: 40
+              PaddingFrameBytes: 0
+              OffsetToPadding: 0
+              BytesOfCalleeSavedRegisters: 0
+              OffsetOfExceptionHandler: 0
+              SectionIdOfExceptionHandler: 0
+              Flags:           [  ]
           - Kind:            S_PROC_ID_END
-            ScopeEndSym:
+            ScopeEndSym:     {}
       - !Lines
         CodeSize:        15
         Flags:           [  ]
         RelocOffset:     0
         RelocSegment:    0
         Blocks:
           - FileName:        '.\foo.h'
             Lines:
               - Offset:          0
                 LineStart:       2
                 IsStatement:     false
                 EndDelta:        0
               - Offset:          4
                 LineStart:       3
                 IsStatement:     false
                 EndDelta:        0
               - Offset:          9
                 LineStart:       4
                 IsStatement:     false
                 EndDelta:        0
-            Columns:
+            Columns:         []
     Relocations:
       - VirtualAddress:  44
         SymbolName:      foo
         Type:            IMAGE_REL_AMD64_SECREL
       - VirtualAddress:  48
         SymbolName:      foo
         Type:            IMAGE_REL_AMD64_SECTION
-      - VirtualAddress:  68
+      - VirtualAddress:  100
         SymbolName:      foo
         Type:            IMAGE_REL_AMD64_SECREL
-      - VirtualAddress:  72
+      - VirtualAddress:  104
         SymbolName:      foo
         Type:            IMAGE_REL_AMD64_SECTION
   - Name:            .pdata
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_LNK_COMDAT, IMAGE_SCN_MEM_READ ]
     Alignment:       4
     SectionData:     000000000F00000000000000
     Relocations:
       - VirtualAddress:  0
         SymbolName:      foo
         Type:            IMAGE_REL_AMD64_ADDR32NB
       - VirtualAddress:  4
         SymbolName:      foo
         Type:            IMAGE_REL_AMD64_ADDR32NB
       - VirtualAddress:  8
-        SymbolName:      .xdata
+        SymbolTableIndex: 11
         Type:            IMAGE_REL_AMD64_ADDR32NB
 symbols:
   - Name:            .text
     Value:           0
     SectionNumber:   1
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
symbols:
   - Name:            foo
     Value:           0
     SectionNumber:   5
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_FUNCTION
     StorageClass:    IMAGE_SYM_CLASS_EXTERNAL
   - Name:            .xdata
     Value:           0
-    SectionNumber:   10
+    SectionNumber:   11
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
       Length:          8
       NumberOfRelocations: 0
       NumberOfLinenumbers: 0
       CheckSum:        264583633
SectionDefinition:
       Number:          6
   - Name:            '.debug$S'
     Value:           0
     SectionNumber:   7
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
-      Length:          264
+      Length:          396
       NumberOfRelocations: 4
       NumberOfLinenumbers: 0
-      CheckSum:        2204933783
+      CheckSum:        3390249978
       Number:          7
   - Name:            '.debug$S'
     Value:           0
-    SectionNumber:   11
+    SectionNumber:   12
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
-      Length:          116
+      Length:          148
       NumberOfRelocations: 4
       NumberOfLinenumbers: 0
-      CheckSum:        2691661839
+      CheckSum:        1236081121
       Number:          5
       Selection:       IMAGE_COMDAT_SELECT_ASSOCIATIVE
   - Name:            '.debug$T'
     Value:           0
     SectionNumber:   8
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
-      Length:          80
+      Length:          2028
       NumberOfRelocations: 0
       NumberOfLinenumbers: 0
-      CheckSum:        3541780432
+      CheckSum:        2043733667
       Number:          8
   - Name:            .pdata
     Value:           0
     SectionNumber:   9
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
       Length:          12
       NumberOfRelocations: 3
       NumberOfLinenumbers: 0
       CheckSum:        567356797
       Number:          9
   - Name:            .pdata
     Value:           0
-    SectionNumber:   12
+    SectionNumber:   13
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
       Length:          12
       NumberOfRelocations: 3
       NumberOfLinenumbers: 0
       CheckSum:        3642757804
       Number:          5
       Selection:       IMAGE_COMDAT_SELECT_ASSOCIATIVE
+  - Name:            .llvm_addrsig
+    Value:           0
+    SectionNumber:   10
+    SimpleType:      IMAGE_SYM_TYPE_NULL
+    ComplexType:     IMAGE_SYM_DTYPE_NULL
+    StorageClass:    IMAGE_SYM_CLASS_STATIC
+    SectionDefinition:
+      Length:          2
+      NumberOfRelocations: 0
+      NumberOfLinenumbers: 0
+      CheckSum:        2582217811
+      Number:          10
+  - Name:            '@feat.00'
+    Value:           0
+    SectionNumber:   -1
+    SimpleType:      IMAGE_SYM_TYPE_NULL
+    ComplexType:     IMAGE_SYM_DTYPE_NULL
+    StorageClass:    IMAGE_SYM_CLASS_STATIC
   - Name:            main
     Value:           0
     SectionNumber:   1
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_FUNCTION
     StorageClass:    IMAGE_SYM_CLASS_EXTERNAL
   - Name:            bar
     Value:           0
     SectionNumber:   0
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_EXTERNAL
+  - Name:            .file
+    Value:           0
+    SectionNumber:   -2
+    SimpleType:      IMAGE_SYM_TYPE_NULL
+    ComplexType:     IMAGE_SYM_DTYPE_NULL
+    StorageClass:    IMAGE_SYM_CLASS_FILE
+    File:            pdb_lines_1.c
 ...

lld/test/COFF/Inputs/pdb_lines_2_relative.yaml

sections:
   - Name:            .data
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_READ, IMAGE_SCN_MEM_WRITE ]
     Alignment:       4
     SectionData:     ''
   - Name:            .bss
     Characteristics: [ IMAGE_SCN_CNT_UNINITIALIZED_DATA, IMAGE_SCN_MEM_READ, IMAGE_SCN_MEM_WRITE ]
     Alignment:       4
     SectionData:     ''
+    SizeOfRawData:   0
   - Name:            .drectve
     Characteristics: [ IMAGE_SCN_LNK_INFO, IMAGE_SCN_LNK_REMOVE ]
     Alignment:       1
     SectionData:     202F44454641554C544C49423A6C6962636D742E6C6962202F44454641554C544C49423A6F6C646E616D65732E6C6962
   - Name:            '.debug$S'
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
     Alignment:       4
-    SectionData:     04000000F10000002F0000002D003C1100000000D0000700000000000000581B000000000000636C616E672076657273696F6E20372E302E30200000F10000002F0000002900471100000000000000000000000001000000000000000000000002100000000000000000006261720002004F1100F2000000200000000000000000000000010000000000000001000000140000000000000002000000F400000018000000010000001001DF91CB3A2B8D917486574BB50CAC4CC70000F300000014000000002E5C7064625F6C696E65735F322E6300000000
     Subsections:
       - !Symbols
         Records:
           - Kind:            S_COMPILE3
             Compile3Sym:
               Flags:           [  ]
               Machine:         X64
-              FrontendMajor:   7
+              FrontendMajor:   11
               FrontendMinor:   0
               FrontendBuild:   0
               FrontendQFE:     0
-              BackendMajor:    7000
+              BackendMajor:    11000
               BackendMinor:    0
               BackendBuild:    0
               BackendQFE:      0
-              Version:         'clang version 7.0.0 '
+              Version:         'clang version 11.0.0 (https://github.com/llvm/llvm-project.git 77dad72eae974338ddc13d74783c012ccbb8c5ac)'
       - !Symbols
         Records:
           - Kind:            S_GPROC32_ID
             ProcSym:
               CodeSize:        1
               DbgStart:        0
               DbgEnd:          0
               FunctionType:    4098
               Flags:           [  ]
               DisplayName:     bar
+          - Kind:            S_FRAMEPROC
+            FrameProcSym:
+              TotalFrameBytes: 0
+              PaddingFrameBytes: 0
+              OffsetToPadding: 0
+              BytesOfCalleeSavedRegisters: 0
+              OffsetOfExceptionHandler: 0
+              SectionIdOfExceptionHandler: 0
+              Flags:           [  ]
           - Kind:            S_PROC_ID_END
-            ScopeEndSym:
+            ScopeEndSym:     {}
       - !Lines
         CodeSize:        1
         Flags:           [  ]
         RelocOffset:     0
         RelocSegment:    0
         Blocks:
           - FileName:        '.\pdb_lines_2.c'
             Lines:
               - Offset:          0
                 LineStart:       2
                 IsStatement:     false
                 EndDelta:        0
-            Columns:
+            Columns:         []
       - !FileChecksums
         Checksums:
           - FileName:        '.\pdb_lines_2.c'
             Kind:            MD5
-            Checksum:        DF91CB3A2B8D917486574BB50CAC4CC7
+            Checksum:        4CC58B73BFD5AB52F87CFB3C604BB288
       - !StringTable
         Strings:
           - '.\pdb_lines_2.c'
           - ''
           - ''
           - ''
+      - !Symbols
+        Records:
+          - Kind:            S_BUILDINFO
+            BuildInfoSym:
+              BuildId:         4103
     Relocations:
-      - VirtualAddress:  100
+      - VirtualAddress:  184
         SymbolName:      bar
         Type:            IMAGE_REL_AMD64_SECREL
-      - VirtualAddress:  104
+      - VirtualAddress:  188
         SymbolName:      bar
         Type:            IMAGE_REL_AMD64_SECTION
-      - VirtualAddress:  124
+      - VirtualAddress:  240
         SymbolName:      bar
         Type:            IMAGE_REL_AMD64_SECREL
-      - VirtualAddress:  128
+      - VirtualAddress:  244
         SymbolName:      bar
         Type:            IMAGE_REL_AMD64_SECTION
   - Name:            '.debug$T'
     Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ]
     Alignment:       4
-    SectionData:     0400000006000112000000000E0008100300000000000000001000000E000116000000000110000062617200
     Types:
       - Kind:            LF_ARGLIST
         ArgList:
           ArgIndices:      [  ]
       - Kind:            LF_PROCEDURE
         Procedure:
           ReturnType:      3
           CallConv:        NearC
           Options:         [ None ]
           ParameterCount:  0
           ArgumentList:    4096
       - Kind:            LF_FUNC_ID
         FuncId:
           ParentScope:     0
           FunctionType:    4097
           Name:            bar
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          .
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          pdb_lines_2.c
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          'buildninjaRel\bin\clang-cl.exe'
+      - Kind:            LF_STRING_ID
+        StringId:
+          Id:              0
+          String:          '"-cc1" "-triple" "x86_64-pc-windows-msvc19.26.28806" "-emit-obj" "-mrelax-all" "-mincremental-linker-compatible" "-disable-free" "-main-file-name" "pdb_lines_2.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mframe-pointer=none" "-relaxed-aliasing" "-fmath-errno" "-fno-rounding-math" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-mllvm" "-x86-asm-syntax=intel" "-D_MT" "-flto-visibility-public-std" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-stack-protector" "2" "-fms-volatile" "-fdiagnostics-format" "msvc" "-gcodeview" "-debug-info-kind=limited" "-resource-dir" "D:\\llvm-project\\buildninjaRel\\lib\\clang\\11.0.0" "-internal-isystem" "D:\\llvm-project\\buildninjaRel\\lib\\clang\\11.0.0\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\VC\\Tools\\MSVC\\14.26.28801\\ATLMFC\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\VC\\Tools\\MSVC\\14.26.28801\\include" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.8\\include\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\ucrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\shared" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\winrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.18362.0\\cppwinrt" "-fdebug-compilation-dir" "." "-ferror-limit" "19" "-fmessage-length=146" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.26.28806" "-fdelayed-template-parsing" "-fcolor-diagnostics" "-faddrsig" "-x" "c"'
+      - Kind:            LF_BUILDINFO
+        BuildInfo:
+          ArgIndices:      [ 4099, 4101, 4100, 0, 4102 ]
+  - Name:            .llvm_addrsig
+    Characteristics: [ IMAGE_SCN_LNK_REMOVE ]
+    Alignment:       1
+    SectionData:     ''
 symbols:
   - Name:            .text
     Value:           0
     SectionNumber:   1
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
SectionDefinition:
       Number:          4
   - Name:            '.debug$S'
     Value:           0
     SectionNumber:   5
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
-      Length:          216
+      Length:          348
       NumberOfRelocations: 4
       NumberOfLinenumbers: 0
-      CheckSum:        2383431754
+      CheckSum:        2408981505
       Number:          5
   - Name:            '.debug$T'
     Value:           0
     SectionNumber:   6
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_NULL
     StorageClass:    IMAGE_SYM_CLASS_STATIC
     SectionDefinition:
-      Length:          44
+      Length:          1992
       NumberOfRelocations: 0
       NumberOfLinenumbers: 0
-      CheckSum:        179171995
+      CheckSum:        1158086003
       Number:          6
+  - Name:            .llvm_addrsig
+    Value:           0
+    SectionNumber:   7
+    SimpleType:      IMAGE_SYM_TYPE_NULL
+    ComplexType:     IMAGE_SYM_DTYPE_NULL
+    StorageClass:    IMAGE_SYM_CLASS_STATIC
+    SectionDefinition:
+      Length:          0
+      NumberOfRelocations: 0
+      NumberOfLinenumbers: 0
+      CheckSum:        0
+      Number:          7
+  - Name:            '@feat.00'
+    Value:           0
+    SectionNumber:   -1
+    SimpleType:      IMAGE_SYM_TYPE_NULL
+    ComplexType:     IMAGE_SYM_DTYPE_NULL
+    StorageClass:    IMAGE_SYM_CLASS_STATIC
   - Name:            bar
     Value:           0
     SectionNumber:   1
     SimpleType:      IMAGE_SYM_TYPE_NULL
     ComplexType:     IMAGE_SYM_DTYPE_FUNCTION
     StorageClass:    IMAGE_SYM_CLASS_EXTERNAL
+  - Name:            .file
+    Value:           0
+    SectionNumber:   -2
+    SimpleType:      IMAGE_SYM_TYPE_NULL
+    ComplexType:     IMAGE_SYM_DTYPE_NULL
+    StorageClass:    IMAGE_SYM_CLASS_FILE
+    File:            pdb_lines_2.c
 ...

lld/test/COFF/pdb-relative-source-lines.test

 int main(void) {
   foo();
   return 42;
 }
 ==> pdb_lines_2.c <==
 void bar(void) {
 }
 
-$ clang-cl -Xclang -fdebug-compilation-dir -Xclang . -c -Z7 pdb_lines*.c
+$ clang-cl -fdebug-compilation-dir . -no-canonical-prefixes -c -Z7 pdb_lines*.c
+$ obj2yaml pdb_lines_1.obj > pdb_lines_1_relative.yaml
+$ obj2yaml pdb_lines_2.obj > pdb_lines_2_relative.yaml
 
 /pdbsourcepath: only sets the directory that relative paths are considered
 relative to, so this test needs to pass relative paths to lld-link for:
 1. The input obj files
 2. The /pdb: switch
 3. The lld-link invocation itself
 To achieve this, put all inputs of the lld-link invocation (including lld-link
 itself) in a temp directory that's cwd and then make sure to only use relative
 arguments when calling ./lld-link below.
 RUN: rm -rf %t
 RUN: mkdir %t
 RUN: cp lld-link %t/lld-link
 RUN: cd %t
 
 RUN: yaml2obj %S/Inputs/pdb_lines_1_relative.yaml -o %t/pdb_lines_1_relative.obj
 RUN: yaml2obj %S/Inputs/pdb_lines_2_relative.yaml -o %t/pdb_lines_2_relative.obj
 RUN: ./lld-link -debug "-pdbsourcepath:c:\src" -entry:main -nodefaultlib -out:out.exe -pdb:out.pdb pdb_lines_1_relative.obj pdb_lines_2_relative.obj
-RUN: llvm-pdbutil pdb2yaml -modules -module-files -module-syms -subsections=lines,fc %t/out.pdb | FileCheck %s
+RUN: llvm-pdbutil pdb2yaml -ipi-stream -modules -module-files -module-syms -subsections=lines,fc %t/out.pdb | FileCheck %s
 RUN: ./lld-link -debug "-pdbsourcepath:/usr/src" -entry:main -nodefaultlib -out:out.exe -pdb:out.pdb pdb_lines_1_relative.obj pdb_lines_2_relative.obj
-RUN: llvm-pdbutil pdb2yaml -modules -module-files -module-syms -subsections=lines,fc %t/out.pdb | FileCheck --check-prefix=POSIX %s
+RUN: llvm-pdbutil pdb2yaml -ipi-stream -modules -module-files -module-syms -subsections=lines,fc %t/out.pdb | FileCheck --check-prefix=POSIX %s
 
 Also check without -pdbsourcepath
 RUN: ./lld-link -debug -entry:main -nodefaultlib -out:out.exe -pdb:out.pdb pdb_lines_1_relative.obj pdb_lines_2_relative.obj
 RUN: llvm-pdbutil pdb2yaml -modules -module-files -module-syms -subsections=lines,fc %t/out.pdb | FileCheck --check-prefix=ABSOLUTE %s
 
 Clean up copy of large binary copied into temp directory to avoid bloat.
 RUN: rm -f ./lld-link || true
 

 CHECK-NEXT:         - 'c:\src'
 CHECK-NEXT:         - exe
 CHECK-NEXT:         - 'c:\src\lld-link'
 CHECK-NEXT:         - pdb 
 CHECK-NEXT:         - 'c:\src\out.pdb'
 CHECK-NEXT:         - cmd
 CHECK-NEXT:         - '-debug -pdbsourcepath:c:\src -entry:main -nodefaultlib -out:out.exe -pdb:out.pdb pdb_lines_1_relative.obj pdb_lines_2_relative.obj'
 
+CHECK-LABEL: IpiStream:
+
+CHECK:    - Kind:            LF_STRING_ID
+CHECK-NEXT:      StringId:
+CHECK-NEXT:        Id:              0
+CHECK-NEXT:        String:          .
+CHECK-NEXT:     - Kind:            LF_STRING_ID
+CHECK-NEXT:       StringId:
+CHECK-NEXT:         Id:              0
+CHECK-NEXT:         String:          pdb_lines_1.c
+CHECK-NEXT:     - Kind:            LF_STRING_ID
+CHECK-NEXT:       StringId:
+CHECK-NEXT:         Id:              0
+CHECK-NEXT:         String:          'buildninjaRel\bin\clang-cl.exe'
 
 POSIX-LABEL:  - Module:          '/usr/src/pdb_lines_1_relative.obj'
 POSIX-NEXT:     ObjFile:         '/usr/src/pdb_lines_1_relative.obj'
 POSIX:          SourceFiles:
 POSIX-NEXT:       - '/usr/src/pdb_lines_1.c'
 POSIX-NEXT:       - '/usr/src/foo.h'
 POSIX:          Subsections:
 POSIX:                - FileName:        '/usr/src/pdb_lines_1.c'

 POSIX-NEXT:         - '/usr/src/lld-link'
 POSIX-NEXT:         - pdb 
 POSIX-NEXT:         - '/usr/src/out.pdb'
 POSIX-NEXT:         - cmd
 POSIX-NEXT:         - '-debug -pdbsourcepath:/usr/src -entry:main -nodefaultlib -out:out.exe -pdb:out.pdb pdb_lines_1_relative.obj pdb_lines_2_relative.obj'
 
 ABSOLUTE-LABEL: StringTable:
 ABSOLUTE-NOT: {{/|\\}}.{{/|\\}}pdb_lines_1.c
+
+POSIX-LABEL: IpiStream:
+POSIX:    - Kind:            LF_STRING_ID
+POSIX-NEXT:      StringId:
+POSIX-NEXT:        Id:              0
+POSIX-NEXT:        String:          .
+POSIX-NEXT:     - Kind:            LF_STRING_ID
+POSIX-NEXT:       StringId:
+POSIX-NEXT:         Id:              0
+POSIX-NEXT:         String:          pdb_lines_1.c
+POSIX-NEXT:     - Kind:            LF_STRING_ID
+POSIX-NEXT:       StringId:
+POSIX-NEXT:         Id:              0
+POSIX-NEXT:         String:          'buildninjaRel\bin\clang-cl.exe'

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

 #include "llvm/Support/BinaryStreamWriter.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/SMLoc.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "llvm/Target/TargetLoweringObjectFile.h"
 #include "llvm/Target/TargetMachine.h"
 #include <algorithm>
 #include <cassert>
 #include <cctype>
 #include <cstddef>

 }
 
 static TypeIndex getStringIdTypeIdx(GlobalTypeTableBuilder &TypeTable,
                                     StringRef S) {
   StringIdRecord SIR(TypeIndex(0x0), S);
   return TypeTable.writeLeafType(SIR);
 }
 
+static std::string flattenCommandLine(ArrayRef<std::string> Args,
+                                      StringRef MainFilename) {
+  std::string FlatCmdLine;
+  raw_string_ostream OS(FlatCmdLine);
+  bool PrintedOneArg = false;
+  if (!StringRef(Args[0]).contains("-cc1")) {
+    llvm::sys::printArg(OS, "-cc1", /*Quote=*/true);
+    PrintedOneArg = true;
+  }
+  for (unsigned i = 0; i < Args.size(); i++) {
+    StringRef Arg = Args[i];
+    if (Arg.empty())
+      continue;
+    if (Arg == "-main-file-name" || Arg == "-o") {
+      i++; // Skip this argument and next one.
+      continue;
+    }
+    if (Arg.startswith("-object-file-name") || Arg == MainFilename)
+      continue;
+    if (PrintedOneArg)
+      OS << " ";
+    llvm::sys::printArg(OS, Arg, /*Quote=*/true);
+    PrintedOneArg = true;
+  }
+  OS.flush();
+  return FlatCmdLine;
+}
+
 void CodeViewDebug::emitBuildInfo() {
   // First, make LF_BUILDINFO. It's a sequence of strings with various bits of
   // build info. The known prefix is:
   // - Absolute path of current directory
   // - Compiler path
   // - Main source file path, relative to CWD or absolute
   // - Type server PDB file
   // - Canonical compiler command line
   // If frontend and backend compilation are separated (think llc or LTO), it's
   // not clear if the compiler path should refer to the executable for the
   // frontend or the backend. Leave it blank for now.
   TypeIndex BuildInfoArgs[BuildInfoRecord::MaxArgs] = {};
   NamedMDNode *CUs = MMI->getModule()->getNamedMetadata("llvm.dbg.cu");
   const MDNode *Node = *CUs->operands().begin(); // FIXME: Multiple CUs.
   const auto *CU = cast<DICompileUnit>(Node);
   const DIFile *MainSourceFile = CU->getFile();
   BuildInfoArgs[BuildInfoRecord::CurrentDirectory] =
       getStringIdTypeIdx(TypeTable, MainSourceFile->getDirectory());
   BuildInfoArgs[BuildInfoRecord::SourceFile] =
       getStringIdTypeIdx(TypeTable, MainSourceFile->getFilename());
-  // FIXME: Path to compiler and command line. PDB is intentionally blank unless
-  // we implement /Zi type servers.
+  // FIXME: PDB is intentionally blank unless we implement /Zi type servers.
+  BuildInfoArgs[BuildInfoRecord::TypeServerPDB] =
+      getStringIdTypeIdx(TypeTable, "");
+  if (Asm->TM.Options.MCOptions.Argv0 != nullptr) {
+    BuildInfoArgs[BuildInfoRecord::BuildTool] =
+        getStringIdTypeIdx(TypeTable, Asm->TM.Options.MCOptions.Argv0);
+    BuildInfoArgs[BuildInfoRecord::CommandLine] = getStringIdTypeIdx(
+        TypeTable, flattenCommandLine(Asm->TM.Options.MCOptions.CommandLineArgs,
+                                      MainSourceFile->getFilename()));
+  }
   BuildInfoRecord BIR(BuildInfoArgs);
   TypeIndex BuildInfoIndex = TypeTable.writeLeafType(BIR);
 
   // Make a new .debug$S subsection for the S_BUILDINFO record, which points
   // from the module symbols into the type stream.
   MCSymbol *BISubsecEnd = beginCVSubsection(DebugSubsectionKind::Symbols);
   MCSymbol *BIEnd = beginSymbolRecord(SymbolKind::S_BUILDINFO);
   OS.AddComment("LF_BUILDINFO index");

llvm/test/DebugInfo/COFF/build-info.ll

 ; RUN: llc -filetype=obj -mtriple i686-pc-windows-msvc %s -o %t.o
 ; RUN: llvm-pdbutil dump %t.o -symbols -types | FileCheck %s
 
 ; CHECK: [[INFO_IDX:0x[^ ]*]] | LF_BUILDINFO
 ; CHECK-NEXT:          0x{{.*}}: `D:\src\scopes\clang`
 ; CHECK-NEXT:          <no type>: ``
 ; CHECK-NEXT:          0x{{.*}}: `D:\src\scopes\foo.cpp`
-; CHECK-NEXT:          <no type>: ``
+; CHECK-NEXT:          0x{{.*}}: ``
 ; CHECK-NEXT:          <no type>: ``
 
 ; CHECK: {{.*}} | S_BUILDINFO [size = 8] BuildId = `[[INFO_IDX]]`
 
 ; ModuleID = 'D:\src\scopes\foo.cpp'
 source_filename = "D:\5Csrc\5Cscopes\5Cfoo.cpp"
 target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
 target triple = "i686-pc-windows-msvc19.0.23918"

llvm/test/DebugInfo/COFF/global-type-hashes.ll

 ; YAML:         - 375C55CDF44B4147
 ; YAML:         - 0634944401BCC520
 ; YAML:         - 6CC0AFB95FA2BFF2
 ; YAML:         - D016F92E5C009314
 ; YAML:         - 74698BE366891D3D
 ; YAML:         - 4470750F2E319329
 ; YAML:         - 0FB556FD1FAB66D7
 ; YAML:         - 5970EFB4874D0F3F
-; YAML:         - EDB1D74C120CF44A
+; YAML:         - D8EF11198C33843F
+; YAML:         - D81F744D7366282B
 ; ...
 
 
 ; ASM:      .section        .debug$H,"dr"
 ; ASM-NEXT: .p2align        2
 ; ASM-NEXT: .long   20171205                # Magic
 ; ASM-NEXT: .short  0                       # Section Version
 ; ASM-NEXT: .short  1                       # Hash Algorithm
 ; ASM-NEXT: .byte   0x80, 0x03, 0x09, 0xee  # 0x1000 [800309EE1ED8BB5B]
 ; ASM-NEXT: .byte   0x1e, 0xd8, 0xbb, 0x5b
 ; ASM-NEXT: .byte   0x53, 0x97, 0x31, 0x9f  # 0x1001 [5397319F1CC14E2C]
 ; ASM-NEXT: .byte   0x1c, 0xc1, 0x4e, 0x2c
 ; ASM-NEXT: .byte   0xdf, 0x04, 0xaa, 0x31  # 0x1002 [DF04AA3125BBC50E]

llvm/test/DebugInfo/COFF/types-basic.ll

 ; ASM: .byte  241
 ; ASM: # StringId (0x1014)
 ; ASM: .short 0xe                     # Record length
 ; ASM: .short 0x1605                  # Record kind: LF_STRING_ID
 ; ASM: .long  0x0                     # Id
 ; ASM: .asciz "t.cpp"                 # StringData
 ; ASM: .byte  242
 ; ASM: .byte  241
-; ASM: # BuildInfo (0x1015)
+; ASM: # StringId (0x1015)
+; ASM: .short 0xa                     # Record length
+; ASM: .short 0x1605                  # Record kind: LF_STRING_ID
+; ASM: .long  0x0                     # Id
+; ASM: .byte    0                       # StringData
+; ASM: .byte  243
+; ASM: .byte  242
+; ASM: .byte  241
+; ASM: # BuildInfo (0x1016)
 ; ASM: .short 0x1a                    # Record length
 ; ASM: .short 0x1603                  # Record kind: LF_BUILDINFO
 ; ASM: .short 0x5                     # NumArgs
 ; ASM: .long  0x1013                  # Argument: D:\src\llvm\build
 ; ASM: .long  0x0                     # Argument
 ; ASM: .long  0x1014                  # Argument: t.cpp
-; ASM: .long  0x0                     # Argument
+; ASM: .long  0x1015                  # Argument
 ; ASM: .long  0x0                     # Argument
 ; ASM: .byte  242
 ; ASM: .byte  241
 
 ; ModuleID = 't.cpp'
 source_filename = "t.cpp"
 target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-pc-windows-msvc19.0.23918"

llvm/test/DebugInfo/COFF/types-data-members.ll

 ; ASM: .byte  241
 ; ASM: # StringId (0x1021)
 ; ASM: .short 0xe                     # Record length
 ; ASM: .short 0x1605                  # Record kind: LF_STRING_ID
 ; ASM: .long  0x0                     # Id
 ; ASM: .asciz "t.cpp"                 # StringData
 ; ASM: .byte  242
 ; ASM: .byte  241
-; ASM: # BuildInfo (0x1022)
+; ASM: # StringId (0x1022)
+; ASM: .short 0xa                     # Record length
+; ASM: .short 0x1605                  # Record kind: LF_STRING_ID
+; ASM: .long  0x0                     # Id
+; ASM: .byte    0                       # StringData
+; ASM: .byte  243
+; ASM: .byte  242
+; ASM: .byte  241
+; ASM: # BuildInfo (0x1023)
 ; ASM: .short 0x1a                    # Record length
 ; ASM: .short 0x1603                  # Record kind: LF_BUILDINFO
 ; ASM: .short 0x5                     # NumArgs
 ; ASM: .long  0x1020                  # Argument: D:\src\llvm\build
 ; ASM: .long  0x0                     # Argument
 ; ASM: .long  0x1021                  # Argument: t.cpp
-; ASM: .long  0x0                     # Argument
+; ASM: .long  0x1022                  # Argument
 ; ASM: .long  0x0                     # Argument
 ; ASM: .byte  242
 ; ASM: .byte  241
 
 ; ModuleID = 't.cpp'
 source_filename = "t.cpp"
 target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-pc-windows-msvc19.0.23918"