[llvm-branch-commits] [clang] release/22.x: [clang][CodeView] Prevent the input name from appearing in LF_BUILDINFO (#194140) (PR #194348)

[Alexandre Ganea via llvm-branch-commits]

aganea wrote:

> Does the CodeView standard actually specify that the input name should not appear in the LF_BUILDINFO output? This superficially to me seems to be a case where a tool was built using the current output of an LLVM tool, it changed and now they want the old behavior back.

Microsoft does not document the debug information records. The only source of information we have is their own internal libraries that were published as some point (on their own agreement). What is seen in regards to `LF_BUILDINFO` is here: https://github.com/microsoft/microsoft-pdb/blob/805655a28bd8198004be2ac27e6e0290121a5e89/include/cvinfo.h#L1718
We can see separate fields in `LF_BUILDINFO` such as `CV_BuildInfo_SourceFile` and for `CV_BuildInfo_CommandArguments`. Their own compiler MSVC `cl.exe` produces binaries that are line with that spec, that is, the source file name (record 0x1005 below) is separated from the command-line (records 0x1007 - 0x100a):
```
>cat main.cpp
int main() {
        return 0;
}
>cl /Z7 main.cpp /c
Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35226 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

main.cpp

>microsoft-pdb\cvdump\cvdump.exe -t main.obj
Microsoft (R) Debugging Information Dumper  Version 14.00.23611
Copyright (C) Microsoft Corporation.  All rights reserved.


***** SECTION #4

*** TYPES

0x1000 : Length = 6, Leaf = 0x1201 LF_ARGLIST argument count = 0

0x1001 : Length = 14, Leaf = 0x1008 LF_PROCEDURE
        Return type = T_INT4(0074), Call type = C Near
        Func attr = none
        # Parms = 0, Arg list type = 0x1000

0x1002 : Length = 26, Leaf = 0x1601 LF_FUNC_ID
        Type = 0x1001           Scope = global  main

0x1003 : Length = 18, Leaf = 0x1605 LF_STRING_ID
        C:\git\test
        No sub string

0x1004 : Length = 114, Leaf = 0x1605 LF_STRING_ID
        C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\cl.exe
        No sub string

0x1005 : Length = 18, Leaf = 0x1605 LF_STRING_ID
        main.cpp
        No sub string

0x1006 : Length = 30, Leaf = 0x1605 LF_STRING_ID
        C:\git\test\vc140.pdb
        No sub string

0x1007 : Length = 242, Leaf = 0x1605 LF_STRING_ID
        -Z7 -c -MT -I"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\include" -I"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\ATLMFC\include" -I"C:\Program Files\Microsoft
        No sub string

0x1008 : Length = 266, Leaf = 0x1605 LF_STRING_ID
         Visual Studio\2022\Community\VC\Auxiliary\VS\include" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\ucrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\um" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\share
        No sub string

0x1009 : Length = 14, Leaf = 0x1604 LF_SUBSTR_LIST
        String ID's (count = 2): 0x1007 0x1008

0x100a : Length = 226, Leaf = 0x1605 LF_STRING_ID
        d" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\winrt" -I"C:\Program Files (x86)\Windows Kits\10\include\10.0.26100.0\cppwinrt" -I"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" -TP -X
        List of sub string ID's = 0x1009

0x100b : Length = 26, Leaf = 0x1603 LF_BUILDINFO
        String ID's (count = 5): 0x1003 0x1004 0x1005 0x1006 0x100A
```

We reproduced in LLVM the same behavior since a whole suite of tools is relying on that behavior.

> Also if the change in behavior happened in LLVM 20, why was it only now noticed and reported?

Mostly because some downstream users are not upgrading as quickly. As far as game developers are concerned, we need to keep the toolchain consistent with other platforms we ship on, and on some these platforms have their own toolchains where we don't control the Clang version used. So in essence we cannot upgrade at our leisure.

> Do they already have a work-around implemented making this non-essential? If so I would prefer to punt this to LLVM 23, but I could be convinced otherwise if there is not a work-around and this is a critical fix.

We don't have a workaround. This bug was noticed only because the version of LLVM (20.1.8) was upgraded recently, tied with a recent integration of Unreal Engine version 5.7. The bug only happens in some edge cases, that's why it went unnoticed. Since this is something that was working prior to version 20, I argue that is should be fixed asap.



https://github.com/llvm/llvm-project/pull/194348