Currently, global variables with local visibility such as the following...
void foo() { static int local = 1; } void bar() { static int local = 3; }
... are emitted in CodeView as global S_LDATA32 entries outside of any routine:
CodeViewDebugInfo [ Section: .debug$S (5) Subsection [ GlobalProcIdSym { Kind: S_GPROC32_ID (0x1147) DisplayName: foo # Routine foo() } ProcEnd { Kind: S_PROC_ID_END (0x114F) } ] Subsection [ GlobalProcIdSym { Kind: S_GPROC32_ID (0x1147) DisplayName: bar # Routine bar() } ProcEnd { Kind: S_PROC_ID_END (0x114F) } ] Subsection [ DataSym { Kind: S_LDATA32 (0x110C) DisplayName: local # "local" inside "foo" LinkageName: ?local@?1??foo@@YAXXZ@4HA } DataSym { Kind: S_LDATA32 (0x110C) DisplayName: local # "local" inside "bar" LinkageName: ?local@?1??bar@@YAXXZ@4HA } ] ]
When debugging routines foo() and bar(), Visual Studio 2017 will locate whichever value for "local" it finds first, which may not be the correct one, and happily display the potentially incorrect value.
This change builds upon the lexical block support added in rL327620 to sort global variables according to lexical scope. The result for the example above after this patch looks like this:
CodeViewDebugInfo [ Section: .debug$S (5) Subsection [ SubSectionType: Symbols (0xF1) GlobalProcIdSym { Kind: S_GPROC32_ID (0x1147) DisplayName: foo # Routine foo() } DataSym { Kind: S_LDATA32 (0x110C) DisplayName: local # "local" inside "foo" LinkageName: ?local@?1??foo@@YAXXZ@4HA } ProcEnd { Kind: S_PROC_ID_END (0x114F) } ] Subsection [ SubSectionType: Symbols (0xF1) GlobalProcIdSym { Kind: S_GPROC32_ID (0x1147) DisplayName: bar # Routine bar() } DataSym { Kind: S_LDATA32 (0x110C) DisplayName: local # "local" inside "bar" LinkageName: ?local@?1??bar@@YAXXZ@4HA } ProcEnd { Kind: S_PROC_ID_END (0x114F) } ] ]
The changes to the test type-quals.ll are index adjustments because of a minor change in the order in which the entries appear. I added the test global_visibility.ll to validate the new scoping behavior.
We really shouldn't make DenseMaps of SmallVectors, but that is a separate issue and I won't ask you to fix it.