[all-commits] [llvm/llvm-project] e48826: Emit the correct flags for the PROC CodeView Debug...

[Andrey Ali Khan Bolshakov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e48826e016e2f427f3b7b1274166aa9aa0ea7f4f
      https://github.com/llvm/llvm-project/commit/e48826e016e2f427f3b7b1274166aa9aa0ea7f4f
  Author: Daniel Paoliello <danpao at microsoft.com>
  Date:   2023-05-03 (Wed, 03 May 2023)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
    M llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h
    M llvm/test/DebugInfo/COFF/fpo-realign-alloca.ll
    M llvm/test/DebugInfo/COFF/fpo-realign-vframe.ll
    M llvm/test/DebugInfo/COFF/frameproc-flags.ll
    M llvm/test/DebugInfo/COFF/function-options.ll
    M llvm/test/DebugInfo/COFF/inlining-header.ll
    M llvm/test/DebugInfo/COFF/inlining.ll
    M llvm/test/DebugInfo/COFF/long-name.ll
    M llvm/test/DebugInfo/COFF/multifunction.ll
    M llvm/test/DebugInfo/COFF/simple.ll
    M llvm/test/DebugInfo/COFF/types-array.ll
    M llvm/test/DebugInfo/COFF/types-basic.ll
    M llvm/test/MC/AArch64/coff-debug.ll

  Log Message:
  -----------
  Emit the correct flags for the PROC CodeView Debug Symbol

The S_LPROC32_ID and S_GPROC32_ID CodeView Debug Symbols have a flags
field which LLVM has had the values for (in the ProcSymFlags enum) but
has never actually set.

These flags are used by Microsoft-internal tooling that leverages debug
information to do binary analysis.

Modified LLVM to set the correct flags:

- ProcSymFlags::HasOptimizedDebugInfo - always set, as this indicates that
debug info is present for optimized builds (if debug info is not emitted
for optimized builds, then LLVM won't emit a debug symbol at all).
- ProcSymFlags::IsNoReturn and ProcSymFlags::IsNoInline - set if the
function has the NoReturn or NoInline attributes respectively.
- ProcSymFlags::HasFP - set if the function requires a frame pointer (per
TargetFrameLowering::hasFP).

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


  Commit: cd93532dfc455255cb2fa553090d14aaa52b106b
      https://github.com/llvm/llvm-project/commit/cd93532dfc455255cb2fa553090d14aaa52b106b
  Author: Bolshakov <bolsh.andrey at yandex.ru>
  Date:   2023-05-03 (Wed, 03 May 2023)

  Changed paths:
    M clang/lib/AST/MicrosoftMangle.cpp
    M clang/test/CodeGenCXX/mangle-class-nttp.cpp
    M clang/test/CodeGenCXX/mangle-ms-templates.cpp

  Log Message:
  -----------
  [MS ABI] Fix C++ mangling references to declarations.

Several issues have been discovered and (hopefully) fixed here:

- Reference NTTPs should be mangled in the same manner as pointer
ones.

-  Pointer fields of class type NTTPs should be treated in the same
manner as reference ones.

- Pointer-to-member fields of class type NTTPs should be treated
differently compared to pointer-to-member NTTPs. Tests on
pointer-to-member-function NTTP class fields added.

- Correct mangling of pointers to anonymous union members.

- A bug in mangling references to subobjects fixed.

- Mangling array subscripts and base class members in references
to subobjects.

Reference NTTP mangling was done back in 2013
in e8fdc06e0dab2e7b98339425dbe369e27e2092a3, and Microsoft might change
mangling algorithm since then. But class type NTTPs are introduced only
in C++20, and the test was written in
b637148ecb62b900872b34eedd78b923bb43c378.
It is strange if the MS ABI had been realy changed, because Microsoft
claims that they maintain ABI stability since VS 2015. I've tested both
on v142 and v143 MSVC toolsets, and they show the same behavior
on the test cases which are changed in this PR. But
pointer-to-member-function NTTP class field mangling has been actually
changed, because it was erroneous in v142, leading to name collisions.

Moreover, pointer-to-member mangling with conversions across class
hierarchy has been enabled.

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


Compare: https://github.com/llvm/llvm-project/compare/1c2b8129e994...cd93532dfc45