Emit the correct flags for the PROC CodeView Debug Symbol

[dpaoliello]

Summary

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

[dpaoliello]

Fixed test failures

[aaron.ballman]

Adding a few extra reviewers to try to get this unstuck (I'm not particularly qualified to review this myself but saw a request for review help in the wild).

[tiagoma]

@rnk Do you know who would be a good person to review this?

[efriedma]

Maybe add a bit of info to the commit message explaining why these flags are useful?

[efriedma]

LGTM

Note that noreturn can be inferred, and clang marks every function noinline at -O0. Since there isn't any public documentation, it's hard to say what impact that has on the expected uses, but just noting it in case you need something different.

[dpaoliello]

Can we please get this merged in?

[efriedma]

I somehow assumed you had commit access; I'll take care of it.

[bolshakov-a]

I suspect these changes have broken SymbolFile/PDB/function-nested-block.test. The first failure here: https://lab.llvm.org/buildbot/#/builders/219/builds/2520. And it's hardly due to my changes.

[dpaoliello]

In D148761#4323950, @bolshakov-a wrote:

I suspect these changes have broken SymbolFile/PDB/function-nested-block.test. The first failure here: https://lab.llvm.org/buildbot/#/builders/219/builds/2520. And it's hardly due to my changes.

I don't understand how this change would have led to that test failing, but I'll have a look when I'm back from vacation on the 12th.

[bolshakov-a]

Thanks! Honestly, I don't know how to reproduce that test results on my Win-x86-64 platform to reveal failure reason.

[aaron.ballman]

In D148761#4324327, @bolshakov-a wrote:

Thanks! Honestly, I don't know how to reproduce that test results on my Win-x86-64 platform to reveal failure reason.

CC @zturner and @clayborg -- this lldb builder has been down for 11 days and there are several failures unrelated to the one in this patch, otherwise I would have reverted this instead of waiting for the author to get back from vacation. Do either of you want to fix or revert to get the bot back into a good state?

[mstorsjo]

FWIW, I also ran into that LLDB test failure on Windows, and reverting this patch does resolve it. (Haven't dug further.)

[omjavaid]

This caused test failure on lldb-aarch64-windows buildbot
https://lab.llvm.org/buildbot/#/builders/219/builds/2520

ldb-shell :: SymbolFile/PDB/function-nested-block.test

kindly revisit the patch, I am going to revert it for now.

Thanks!

[dpaoliello]

@omjavaid this change DID NOT CAUSE THE TEST FAILURE, please see the previous comments where we were discussing this:

In D148761#4326518, @aaron.ballman wrote:

In D148761#4324327, @bolshakov-a wrote:

Thanks! Honestly, I don't know how to reproduce that test results on my Win-x86-64 platform to reveal failure reason.

CC @zturner and @clayborg -- this lldb builder has been down for 11 days and there are several failures unrelated to the one in this patch, otherwise I would have reverted this instead of waiting for the author to get back from vacation. Do either of you want to fix or revert to get the bot back into a good state?

[omjavaid]

In D148761#4343485, @dpaoliello wrote:

@omjavaid this change DID NOT CAUSE THE TEST FAILURE, please see the previous comments where we were discussing this:

In D148761#4326518, @aaron.ballman wrote:

In D148761#4324327, @bolshakov-a wrote:

Thanks! Honestly, I don't know how to reproduce that test results on my Win-x86-64 platform to reveal failure reason.

CC @zturner and @clayborg -- this lldb builder has been down for 11 days and there are several failures unrelated to the one in this patch, otherwise I would have reverted this instead of waiting for the author to get back from vacation. Do either of you want to fix or revert to get the bot back into a good state?

I am the owner of lldb-aarch64-windows and i have verified that exactly this commit caused the test to fail. The builder was failing a few test earlier thats why this particular failure got masked.

[aaron.ballman]

In D148761#4343528, @omjavaid wrote:

In D148761#4343485, @dpaoliello wrote:

@omjavaid this change DID NOT CAUSE THE TEST FAILURE, please see the previous comments where we were discussing this:

In D148761#4326518, @aaron.ballman wrote:

In D148761#4324327, @bolshakov-a wrote:

Thanks! Honestly, I don't know how to reproduce that test results on my Win-x86-64 platform to reveal failure reason.

CC @zturner and @clayborg -- this lldb builder has been down for 11 days and there are several failures unrelated to the one in this patch, otherwise I would have reverted this instead of waiting for the author to get back from vacation. Do either of you want to fix or revert to get the bot back into a good state?

I am the owner of lldb-aarch64-windows and i have verified that exactly this commit caused the test to fail. The builder was failing a few test earlier thats why this particular failure got masked.

Did you verify that the failure was because the changes were incorrect? These changes are correcting a bug and it's expected that downstreams like lldb may have to react to that sort of thing breaking their tests. A revert ~10 days after the failure landed is not exactly a timely revert -- now all the downstreams that did react to this change will have to react again, which is why I'm curious what amount of analysis was done prior to reverting and what details you can share about the problem.

[omjavaid]

In D148761#4343870, @aaron.ballman wrote:

In D148761#4343528, @omjavaid wrote:

In D148761#4343485, @dpaoliello wrote:

@omjavaid this change DID NOT CAUSE THE TEST FAILURE, please see the previous comments where we were discussing this:

In D148761#4326518, @aaron.ballman wrote:

In D148761#4324327, @bolshakov-a wrote:

Thanks! Honestly, I don't know how to reproduce that test results on my Win-x86-64 platform to reveal failure reason.

CC @zturner and @clayborg -- this lldb builder has been down for 11 days and there are several failures unrelated to the one in this patch, otherwise I would have reverted this instead of waiting for the author to get back from vacation. Do either of you want to fix or revert to get the bot back into a good state?

I am the owner of lldb-aarch64-windows and i have verified that exactly this commit caused the test to fail. The builder was failing a few test earlier thats why this particular failure got masked.

Did you verify that the failure was because the changes were incorrect? These changes are correcting a bug and it's expected that downstreams like lldb may have to react to that sort of thing breaking their tests. A revert ~10 days after the failure landed is not exactly a timely revert -- now all the downstreams that did react to this change will have to react again, which is why I'm curious what amount of analysis was done prior to reverting and what details you can share about the problem.

HI AAron
I do apologise for the inconvenience this may have caused.
We normally try to be proactive with reverts but this was delayed as I was holidays past 10 days.
Regarding revert decision I believe the general community guideline is to revert any patches that cause a regression thats why I have reverted the change and I do agree with correctness of the patch.
Let me debug the issue further and get back to you with more information on why the test is failing.
Thanks

[omjavaid]

Hi Aaron,

The problem seems to be appearing in lldb-test tool which in this case is being used to fetch symbol information. Specifically it fails to find function name inside a nested block with your patch applied. More investigation on LLDB side is needed to find the exact cause of this failure.

You may re-land your changes as they are already approved and kindly mark the LLDB test as xfail.

[aaron.ballman]

In D148761#4344803, @omjavaid wrote:

In D148761#4343870, @aaron.ballman wrote:

In D148761#4343528, @omjavaid wrote:

I am the owner of lldb-aarch64-windows and i have verified that exactly this commit caused the test to fail. The builder was failing a few test earlier thats why this particular failure got masked.

Did you verify that the failure was because the changes were incorrect? These changes are correcting a bug and it's expected that downstreams like lldb may have to react to that sort of thing breaking their tests. A revert ~10 days after the failure landed is not exactly a timely revert -- now all the downstreams that did react to this change will have to react again, which is why I'm curious what amount of analysis was done prior to reverting and what details you can share about the problem.

HI AAron
I do apologise for the inconvenience this may have caused.
We normally try to be proactive with reverts but this was delayed as I was holidays past 10 days.
Regarding revert decision I believe the general community guideline is to revert any patches that cause a regression thats why I have reverted the change and I do agree with correctness of the patch.

Our revert policy is at: https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy and it does encourage timely reverts to regressions, but 1) this change doesn't appear to be a regression, 2) this revert was not timely. Correct, conforming changes to Clang or LLVM that break lldb are not a reason to revert the changes in Clang or LLVM. lldb is a downstream consumer of these tools and will sometimes need to react to changes that break their tests (Clang and LLVM developers will of course try not to be disruptive though!). Just something to keep in mind for next time, not the end of the world. :-)

In D148761#4345436, @omjavaid wrote:

Hi Aaron,

The problem seems to be appearing in lldb-test tool which in this case is being used to fetch symbol information. Specifically it fails to find function name inside a nested block with your patch applied. More investigation on LLDB side is needed to find the exact cause of this failure.

You may re-land your changes as they are already approved and kindly mark the LLDB test as xfail.

Thank you for doing the investigation! @efriedma, can you re-land this for @dpaoliello?

lldb/test/Shell/SymbolFile/PDB/function-nested-block.test

 REQUIRES: system-windows, lld
 RUN: %build --compiler=clang-cl --nodefaultlib --output=%t.exe %S/Inputs/FunctionNestedBlockTest.cpp
 RUN: lldb-test symbols -find=function -file FunctionNestedBlockTest.cpp -line 4 %t.exe | FileCheck --check-prefix=CHECK-FUNCTION %s
 RUN: lldb-test symbols -find=block -file FunctionNestedBlockTest.cpp -line 4 %t.exe | FileCheck --check-prefix=CHECK-BLOCK %s
+XFAIL: *
 
 CHECK-FUNCTION: Found 1 functions:
 CHECK-FUNCTION: name = "{{.*}}", mangled = "{{_?}}main"
 
 CHECK-BLOCK: Found 1 blocks:
 CHECK-BLOCK: Blocks: id = {{.*}}, range = {{.*}}
 CHECK-BLOCK:         id = {{.*}}, range = {{.*}}

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h

struct FunctionInfo {
     codeview::EncodedFramePtrReg EncodedParamFramePtrReg =
         codeview::EncodedFramePtrReg::None;
 
     codeview::FrameProcedureOptions FrameProcOpts;
 
     bool HasStackRealignment = false;
 
     bool HaveLineInfo = false;
+
+    bool HasFramePointer = false;
   };
   FunctionInfo *CurFn = nullptr;
 
   codeview::SourceLanguage CurrentSourceLanguage =
       codeview::SourceLanguage::Masm;
 
   // This map records the constant offset in DIExpression of the
   // DIGlobalVariableExpression referencing the DIGlobalVariable.

llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp

MCSymbol *SymbolsEnd = beginCVSubsection(DebugSubsectionKind::Symbols);
     OS.emitInt32(0);
     OS.AddComment("Function type index");
     OS.emitInt32(getFuncIdForSubprogram(GV->getSubprogram()).getIndex());
     OS.AddComment("Function section relative address");
     OS.emitCOFFSecRel32(Fn, /*Offset=*/0);
     OS.AddComment("Function section index");
     OS.emitCOFFSectionIndex(Fn);
     OS.AddComment("Flags");
-    OS.emitInt8(0);
+    ProcSymFlags ProcFlags = ProcSymFlags::HasOptimizedDebugInfo;
+    if (FI.HasFramePointer)
+      ProcFlags |= ProcSymFlags::HasFP;
+    if (GV->hasFnAttribute(Attribute::NoReturn))
+      ProcFlags |= ProcSymFlags::IsNoReturn;
+    if (GV->hasFnAttribute(Attribute::NoInline))
+      ProcFlags |= ProcSymFlags::IsNoInline;
+    OS.emitInt8(static_cast<uint8_t>(ProcFlags));
     // Emit the function display name as a null-terminated string.
     OS.AddComment("Function name");
     // Truncate the name so we won't overflow the record length field.
     emitNullTerminatedSymbolName(OS, FuncName);
     endSymbolRecord(ProcRecordEnd);
 
     MCSymbol *FrameProcEnd = beginSymbolRecord(SymbolKind::S_FRAMEPROC);
     // Subtract out the CSR size since MSVC excludes that and we include it.
void CodeViewDebug::beginFunctionImpl(const MachineFunction *MF) {
   // will be the frame pointer.
   CurFn->EncodedParamFramePtrReg = EncodedFramePtrReg::None; // None.
   CurFn->EncodedLocalFramePtrReg = EncodedFramePtrReg::None; // None.
   if (CurFn->FrameSize > 0) {
     if (!TSI.getFrameLowering()->hasFP(*MF)) {
       CurFn->EncodedLocalFramePtrReg = EncodedFramePtrReg::StackPtr;
       CurFn->EncodedParamFramePtrReg = EncodedFramePtrReg::StackPtr;
     } else {
+      CurFn->HasFramePointer = true;
       // If there is an FP, parameters are always relative to it.
       CurFn->EncodedParamFramePtrReg = EncodedFramePtrReg::FramePtr;
       if (CurFn->HasStackRealignment) {
         // If the stack needs realignment, locals are relative to SP or VFRAME.
         CurFn->EncodedLocalFramePtrReg = EncodedFramePtrReg::StackPtr;
       } else {
         // Otherwise, locals are relative to EBP, and we probably have VLAs or
         // other stack adjustments.

llvm/test/DebugInfo/COFF/fpo-realign-alloca.ll

 ; RUN: llc < %s | FileCheck %s
+; RUN: llc -mtriple=i686-windows-msvc < %s -filetype=obj | llvm-readobj --codeview - | FileCheck %s --check-prefix=OBJ
 
 ; C source:
 ; void usethings(ptr, ptr p);
 ; int realign_and_alloca(int n) {
 ;   double d = 0;
 ;   ptr p = __builtin_alloca(n);
 ;   usethings(&d, p);
 ;   return 0;

 ; CHECK:         addl    $8, %esp
 ; CHECK:         xorl    %eax, %eax
 ; CHECK:         leal    -4(%ebp), %esp
 ; CHECK:         popl    %esi
 ; CHECK:         popl    %ebp
 ; CHECK:         retl
 ; CHECK:         .cv_fpo_endproc
 
+; OBJ-LABEL:     FunctionType: realign_and_alloca (0x1002)
+; OBJ-NEXT:      CodeOffset: _realign_and_alloca+0x0
+; OBJ-NEXT:      Segment: 0x0
+; OBJ-NEXT:      Flags [ (0x81)
+; OBJ-NEXT:        HasFP (0x1)
+; OBJ-NEXT:        HasOptimizedDebugInfo (0x80)
+; OBJ-NEXT:      ]
+; OBJ-NEXT:      DisplayName: realign_and_alloca
+; OBJ-NEXT:      LinkageName: _realign_and_alloca
 
 ; ModuleID = 't.c'
 source_filename = "t.c"
 target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
 target triple = "i386-pc-windows-msvc19.11.25508"
 
 ; Function Attrs: nounwind
 define i32 @realign_and_alloca(i32 %n) local_unnamed_addr #0 !dbg !8 {

llvm/test/DebugInfo/COFF/fpo-realign-vframe.ll

 ; OBJ-NEXT:   $ebp $T1 4 - ^ =
 ; OBJ-NEXT: ]
 ; OBJ:   }
 ; OBJ: ]
 ; OBJ: Subsection [
 ; OBJ:   SubSectionType: Symbols (0xF1)
 ; OBJ:   GlobalProcIdSym {
 ; OBJ:     Kind: S_GPROC32_ID (0x1147)
+; OBJ:     Flags [ (0x81)
+; OBJ:       HasFP (0x1)
+; OBJ:       HasOptimizedDebugInfo (0x80)
+; OBJ:     ]
 ; OBJ:     DisplayName: realign_with_csrs
 ; OBJ:     LinkageName: _realign_with_csrs
 ; OBJ:   }
 ;   The frame register for locals should be VFRAME, and EBP for parameters.
 ; OBJ:   FrameProcSym {
 ; OBJ:     Kind: S_FRAMEPROC (0x1012)
 ; OBJ:     TotalFrameBytes: 0x14
 ; OBJ:     LocalFramePtrReg: VFRAME (0x7536)

llvm/test/DebugInfo/COFF/frameproc-flags.ll

 ;
 ; void stack_guard() {
 ;   int arr[12] = {0};
 ;   use_intptr(&arr[0]);
 ; }
 ; }
 
 ; CHECK-LABEL: S_GPROC32_ID [size = 52] `use_alloca`
+; CHECK:   type = `0x1002 (use_alloca)`, debug start = 0, debug end = 0, flags = has fp | opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = VFRAME, param fp reg = EBP
 ; CHECK:   flags = has alloca | secure checks | strict secure checks | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 52] `call_setjmp`
+; CHECK:   type = `0x1003 (call_setjmp)`, debug start = 0, debug end = 0, flags = opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = NONE, param fp reg = NONE
 ; CHECK:   flags = has setjmp | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 56] `use_inlineasm`
+; CHECK:   type = `0x1006 (use_inlineasm)`, debug start = 0, debug end = 0, flags = opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = NONE, param fp reg = NONE
 ; CHECK:   flags = has inline asm | safe buffers | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 48] `cpp_eh`
+; CHECK:   type = `0x1007 (cpp_eh)`, debug start = 0, debug end = 0, flags = has fp | opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = EBP, param fp reg = EBP
 ; CHECK:   flags = has eh | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 52] `use_inline`
+; CHECK:   type = `0x100C (use_inline)`, debug start = 0, debug end = 0, flags = opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = NONE, param fp reg = NONE
 ; CHECK:   flags = safe buffers | opt speed
 ; CHECK-LABEL: S_LPROC32_ID [size = 56] `is_marked_inline`
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = NONE, param fp reg = NONE
 ; CHECK:   flags = marked inline | safe buffers | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 44] `seh`
+; CHECK:   type = `0x100E (seh)`, debug start = 0, debug end = 0, flags = has fp | opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = EBP, param fp reg = EBP
 ; CHECK:   flags = has seh | opt speed
 ; CHECK-LABEL: S_LPROC32_ID [size = 56] `?filt$0@0@seh@@`
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = EBP, param fp reg = EBP
 ; CHECK:   flags = safe buffers | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 52] `use_naked`
+; CHECK:   type = `0x1010 (use_naked)`, debug start = 0, debug end = 0, flags = noinline | opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = NONE, param fp reg = NONE
 ; CHECK:   flags = has inline asm | naked | safe buffers | opt speed
 ; CHECK-LABEL: S_GPROC32_ID [size = 52] `stack_guard`
+; CHECK:   type = `0x1011 (stack_guard)`, debug start = 0, debug end = 0, flags = opt debuginfo
 ; CHECK: S_FRAMEPROC [size = 32]
 ; CHECK:   local fp reg = VFRAME, param fp reg = VFRAME
 ; CHECK:   flags = secure checks | strict secure checks | opt speed
 
 ; ModuleID = 'frameproc-flags.cpp'
 source_filename = "frameproc-flags.cpp"
 target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
 target triple = "i386-pc-windows-msvc19.14.26433"

llvm/test/DebugInfo/COFF/function-options.ll

 ; CHECK:   FuncId ({{.*}}) {
 ; CHECK:     TypeLeafKind: LF_FUNC_ID (0x1601)
 ; CHECK:     ParentScope: 0x0
 ; CHECK:     FunctionType: BUnion (BUnion&) ([[SP_BU]])
 ; CHECK:     Name: Func_BUnion
 ; CHECK:   }
 ; CHECK: ]
 
+; CHECK-LABEL: FunctionType: Func_AClass (0x1008)
+; CHECK-NEXT:  CodeOffset: ?Func_AClass@@YA?AVAClass@@AEAV1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_AClass
+; CHECK-NEXT:  LinkageName: ?Func_AClass@@YA?AVAClass@@AEAV1@@Z
+; CHECK-LABEL: FunctionType: Func_BClass (0x1013)
+; CHECK-NEXT:  CodeOffset: ?Func_BClass@@YA?AVBClass@@AEAV1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_BClass
+; CHECK-NEXT:  LinkageName: ?Func_BClass@@YA?AVBClass@@AEAV1@@Z
+; CHECK-LABEL: FunctionType: Func_C1Class (0x101D)
+; CHECK-NEXT:  CodeOffset: ?Func_C1Class@@YA?AVC1Class@@AEAV1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_C1Class
+; CHECK-NEXT:  LinkageName: ?Func_C1Class@@YA?AVC1Class@@AEAV1@@Z
+; CHECK-LABEL: FunctionType: Func_C2Class (0x1027)
+; CHECK-NEXT:  CodeOffset: ?Func_C2Class@@YA?AVC2Class@@AEAV1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_C2Class
+; CHECK-NEXT:  LinkageName: ?Func_C2Class@@YA?AVC2Class@@AEAV1@@Z
+; CHECK-LABEL: FunctionType: Func_DClass (0x102F)
+; CHECK-NEXT:  CodeOffset: ?Func_DClass@@YA?AVDClass@@AEAV1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_DClass
+; CHECK-NEXT:  LinkageName: ?Func_DClass@@YA?AVDClass@@AEAV1@@Z
+; CHECK-LABEL: FunctionType: Func_FClass (0x103A)
+; CHECK-NEXT:  CodeOffset: ?Func_FClass@@YA?AVFClass@@AEAV1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_FClass
+; CHECK-NEXT:  LinkageName: ?Func_FClass@@YA?AVFClass@@AEAV1@@Z
+; CHECK-LABEL: FunctionType: Func_AStruct (0x1041)
+; CHECK-NEXT:  CodeOffset: ?Func_AStruct@@YA?AUAStruct@@AEAU1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_AStruct
+; CHECK-NEXT:  LinkageName: ?Func_AStruct@@YA?AUAStruct@@AEAU1@@Z
+; CHECK-LABEL: FunctionType: Func_BStruct (0x104B)
+; CHECK-NEXT:  CodeOffset: ?Func_BStruct@@YA?AUBStruct@@AEAU1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_BStruct
+; CHECK-NEXT:  LinkageName: ?Func_BStruct@@YA?AUBStruct@@AEAU1@@Z
+; CHECK-LABEL: FunctionType: Func_AUnion (0x1052)
+; CHECK-NEXT:  CodeOffset: ?Func_AUnion@@YA?ATAUnion@@AEAT1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_AUnion
+; CHECK-NEXT:  LinkageName: ?Func_AUnion@@YA?ATAUnion@@AEAT1@@Z
+; CHECK-LABEL: FunctionType: Func_BUnion (0x105C)
+; CHECK-NEXT:  CodeOffset: ?Func_BUnion@@YA?ATBUnion@@AEAT1@@Z+0x0
+; CHECK-NEXT:  Segment: 0x0
+; CHECK-NEXT:  Flags [ (0xC0)
+; CHECK-NEXT:    HasOptimizedDebugInfo (0x80)
+; CHECK-NEXT:    IsNoInline (0x40)
+; CHECK-NEXT:  ]
+; CHECK-NEXT:  DisplayName: Func_BUnion
+; CHECK-NEXT:  LinkageName: ?Func_BUnion@@YA?ATBUnion@@AEAT1@@Z
+
 ; ModuleID = 't.cpp'
 source_filename = "t.cpp"
 target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-pc-windows-msvc19.23.28106"
 
 %class.AClass = type { i8 }
 %class.BClass = type { i8 }
 %class.C1Class = type { i8 }

llvm/test/DebugInfo/COFF/inlining-header.ll

 
 ; OBJ: Subsection [
 ; OBJ:   SubSectionType: Symbols (0xF1)
 ; OBJ:   {{.*}}Proc{{.*}}Sym {
 ; OBJ:     Kind: S_GPROC32_ID (0x1147)
 ; OBJ:     FunctionType: main (0x1005)
 ; OBJ:     CodeOffset: _main+0x0
 ; OBJ:     Segment: 0x0
-; OBJ:     Flags [ (0x0)
+; OBJ:     Flags [ (0x80)
+; OBJ:       HasOptimizedDebugInfo (0x80)
 ; OBJ:     ]
 ; OBJ:     DisplayName: main
 ; OBJ:     LinkageName: _main
 ; OBJ:   }
 
 ; Previously, g's InlineSiteSym referenced t.h, which was wasteful.
 ; OBJ:        InlineSiteSym {
 ; OBJ:          Inlinee: g (0x1002)

llvm/test/DebugInfo/COFF/inlining.ll

 ; OBJ:     PtrEnd: 0x0
 ; OBJ:     PtrNext: 0x0
 ; OBJ:     CodeSize: 0x35
 ; OBJ:     DbgStart: 0x0
 ; OBJ:     DbgEnd: 0x0
 ; OBJ:     FunctionType: baz (0x1004)
 ; OBJ:     CodeOffset: ?baz@@YAXXZ+0x0
 ; OBJ:     Segment: 0x0
-; OBJ:     Flags [ (0x0)
+; OBJ:     Flags [ (0x80)
+; OBJ:       HasOptimizedDebugInfo (0x80)
 ; OBJ:     ]
 ; OBJ:     DisplayName: baz
 ; OBJ:     LinkageName: ?baz@@YAXXZ
 ; OBJ:   }
 ; OBJ:   InlineSiteSym {
 ; OBJ:     PtrParent: 0x0
 ; OBJ:     PtrEnd: 0x0
 ; OBJ:     Inlinee: bar (0x1002)

llvm/test/DebugInfo/COFF/long-name.ll

 ; RUN: llc < %s -filetype=obj | llvm-readobj --codeview - | FileCheck %s
 
 ; CHECK: {{.*}}Proc{{.*}}Sym {
 ; CHECK:   Kind: S_GPROC32_ID (0x1147)
 ; CHECK:   FunctionType: {{A+}} (0x1002)
 ; CHECK:   CodeOffset: f+0x0
 ; CHECK:   Segment: 0x0
-; CHECK:   Flags [ (0x0)
+; CHECK:   Flags [ (0x80)
+; CHECK:     HasOptimizedDebugInfo (0x80)
 ; CHECK:   ]
 ; CHECK:   DisplayName: {{A+$}}
 ; CHECK:   LinkageName: f
 ; CHECK: }
 ; CHECK: ProcEnd {
 ; CHECK: }
 
 ; CHECK: GlobalData {

llvm/test/DebugInfo/COFF/multifunction.ll

 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long [[END_OF_X]]-_x
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   4098
 ; X86-NEXT: .secrel32 _x
 ; X86-NEXT: .secidx _x
-; X86-NEXT: .byte   0
+; X86-NEXT: .byte   128
 ; X86-NEXT: .asciz "x"
 ; X86-NEXT: .p2align 2
 ; X86-NEXT: [[PROC_SEGMENT_END]]:
 ; X86-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X86-NEXT: [[FPROC_BEG]]:
 ; X86-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X86-NEXT: .long   0                       # FrameSize
 ; X86-NEXT: .long   0                       # Padding

 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long [[END_OF_Y]]-_y
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   4099
 ; X86-NEXT: .secrel32 _y
 ; X86-NEXT: .secidx _y
-; X86-NEXT: .byte   0
+; X86-NEXT: .byte   128
 ; X86-NEXT: .asciz "y"
 ; X86-NEXT: .p2align 2
 ; X86-NEXT: [[PROC_SEGMENT_END]]:
 ; X86-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X86-NEXT: [[FPROC_BEG]]:
 ; X86-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X86-NEXT: .long   0                       # FrameSize
 ; X86-NEXT: .long   0                       # Padding

 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long [[END_OF_F]]-_f
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   4100
 ; X86-NEXT: .secrel32 _f
 ; X86-NEXT: .secidx _f
-; X86-NEXT: .byte   0
+; X86-NEXT: .byte   128
 ; X86-NEXT: .asciz "f"
 ; X86-NEXT: .p2align 2
 ; X86-NEXT: [[PROC_SEGMENT_END]]:
 ; X86-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X86-NEXT: [[FPROC_BEG]]:
 ; X86-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X86-NEXT: .long   0                       # FrameSize
 ; X86-NEXT: .long   0                       # Padding

 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long [[END_OF_X]]-x
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   4098
 ; X64-NEXT: .secrel32 x
 ; X64-NEXT: .secidx x
-; X64-NEXT: .byte   0
+; X64-NEXT: .byte   128
 ; X64-NEXT: .asciz "x"
 ; X64-NEXT: .p2align 2
 ; X64-NEXT: [[PROC_SEGMENT_END]]:
 ; X64-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X64-NEXT: [[FPROC_BEG]]:
 ; X64-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X64-NEXT: .long   40                       # FrameSize
 ; X64-NEXT: .long   0                       # Padding

 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long [[END_OF_Y]]-y
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   4099
 ; X64-NEXT: .secrel32 y
 ; X64-NEXT: .secidx y
-; X64-NEXT: .byte   0
+; X64-NEXT: .byte   128
 ; X64-NEXT: .asciz "y"
 ; X64-NEXT: .p2align 2
 ; X64-NEXT: [[PROC_SEGMENT_END]]:
 ; X64-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X64-NEXT: [[FPROC_BEG]]:
 ; X64-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X64-NEXT: .long   40                       # FrameSize
 ; X64-NEXT: .long   0                       # Padding

 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long [[END_OF_F]]-f
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   4100
 ; X64-NEXT: .secrel32 f
 ; X64-NEXT: .secidx f
-; X64-NEXT: .byte   0
+; X64-NEXT: .byte   128
 ; X64-NEXT: .asciz "f"
 ; X64-NEXT: .p2align 2
 ; X64-NEXT: [[PROC_SEGMENT_END]]:
 ; X64-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X64-NEXT: [[FPROC_BEG]]:
 ; X64-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X64-NEXT: .long   40                       # FrameSize
 ; X64-NEXT: .long   0                       # Padding

llvm/test/DebugInfo/COFF/simple.ll

 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long [[END_OF_F]]-_f
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   0
 ; X86-NEXT: .long   4098
 ; X86-NEXT: .secrel32 _f
 ; X86-NEXT: .secidx _f
-; X86-NEXT: .byte   0
+; X86-NEXT: .byte   128
 ; X86-NEXT: .asciz "f"
 ; X86-NEXT: .p2align 2
 ; X86-NEXT: [[PROC_SEGMENT_END]]:
 ; X86-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X86-NEXT: [[FPROC_BEG]]:
 ; X86-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X86-NEXT: .long   0                       # FrameSize
 ; X86-NEXT: .long   0                       # Padding

 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long [[END_OF_F]]-f
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   0
 ; X64-NEXT: .long   4098
 ; X64-NEXT: .secrel32 f
 ; X64-NEXT: .secidx f
-; X64-NEXT: .byte   0
+; X64-NEXT: .byte   128
 ; X64-NEXT: .asciz "f"
 ; X64-NEXT: .p2align 2
 ; X64-NEXT: [[PROC_SEGMENT_END]]:
 ; X64-NEXT: .short  [[FPROC_END:[^ ]*]]-[[FPROC_BEG:[^ ]*]]           # Record length
 ; X64-NEXT: [[FPROC_BEG]]:
 ; X64-NEXT: .short  4114                    # Record kind: S_FRAMEPROC
 ; X64-NEXT: .long   40                       # FrameSize
 ; X64-NEXT: .long   0                       # Padding

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

 ; CHECK:       PtrEnd: 0x0
 ; CHECK:       PtrNext: 0x0
 ; CHECK:       CodeSize: 0x39
 ; CHECK:       DbgStart: 0x0
 ; CHECK:       DbgEnd: 0x0
 ; CHECK:       FunctionType: f (0x1002)
 ; CHECK:       CodeOffset: ?f@@YAXXZ+0x0
 ; CHECK:       Segment: 0x0
-; CHECK:       Flags [ (0x0)
+; CHECK:       Flags [ (0x81)
+; CHECK:         HasFP (0x1)
+; CHECK:         HasOptimizedDebugInfo (0x80)
 ; CHECK:       ]
 ; CHECK:       DisplayName: f
 ; CHECK:       LinkageName: ?f@@YAXXZ
 ; CHECK:     }
 ; CHECK:     LocalSym {
 ; CHECK:       Type: 0x1003
 ; CHECK:       Flags [ (0x0)
 ; CHECK:       ]

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

 ; CHECK:   Subsection [
 ; CHECK:     SubSectionType: Symbols (0xF1)
 ; CHECK:     {{.*}}Proc{{.*}}Sym {
 ; CHECK:       DbgStart: 0x0
 ; CHECK:       DbgEnd: 0x0
 ; CHECK:       FunctionType: f (0x1002)
 ; CHECK:       CodeOffset: ?f@@YAXMN_J@Z+0x0
 ; CHECK:       Segment: 0x0
-; CHECK:       Flags [ (0x0)
+; CHECK:       Flags [ (0x80)
+; CHECK:         HasOptimizedDebugInfo (0x80)
 ; CHECK:       ]
 ; CHECK:       DisplayName: f
 ; CHECK:       LinkageName: ?f@@YAXMN_J@Z
 ; CHECK:     }
 ; CHECK:     LocalSym {
 ; CHECK:       Type: float (0x40)
 ; CHECK:       Flags [ (0x1)
 ; CHECK:         IsParameter (0x1)

llvm/test/MC/AArch64/coff-debug.ll

 ; CHECK:       PtrEnd: 0x0
 ; CHECK:       PtrNext: 0x0
 ; CHECK:       CodeSize: 0x14
 ; CHECK:       DbgStart: 0x0
 ; CHECK:       DbgEnd: 0x0
 ; CHECK:       FunctionType: main (0x1002)
 ; CHECK:       CodeOffset: main+0x0
 ; CHECK:       Segment: 0x0
-; CHECK:       Flags [ (0x0)
+; CHECK:       Flags [ (0xC0)
+; CHECK:         HasOptimizedDebugInfo (0x80)
+; CHECK:         IsNoInline (0x40)
 ; CHECK:       ]
 ; CHECK:       DisplayName: main
 ; CHECK:       LinkageName: main
 ; CHECK:     }
 ; CHECK:     ProcEnd {
 ; CHECK:       Kind: S_PROC_ID_END (0x114F)
 ; CHECK:     }
 ; CHECK:   ]