[NFC] Refactor how CFI section types are represented in AsmPrinter

[RamNalamothu]

Summary

In terms of readability, the enum CFIMoveType didn't better document what it
intends to convey i.e. the type of CFI section that gets emitted.

[scott.linder]

Add a missing prototype

[scott.linder]

Rebase and fix a callsite

[scott.linder]

Rebase and ping

[MaskRay]

Thanks for refactoring it:) I dug up a bit of history. @asl introduced the variable shouldEmitMoves in rL123474 and espindola introduced the member function needsCFIMoves.
I cannot find "CFI move section" in standards so it is probably not a standard term. Should we use a more appropriate term to best capture the intention?

[scott.linder]

In D76519#2449652, @MaskRay wrote:

Thanks for refactoring it:) I dug up a bit of history. @asl introduced the variable shouldEmitMoves in rL123474 and espindola introduced the member function needsCFIMoves.
I cannot find "CFI move section" in standards so it is probably not a standard term. Should we use a more appropriate term to best capture the intention?

I don't know if there is a generally accepted term to encompass .debug_frame+.eh_frame? Maybe just "CFI section"? Or "section containing CFI"?

I can change the shortlog message to:

[NFC] Refactor AsmPrinter tracking of CFI sections

And the comment to:

// Flags representing which sections to emit CFI to.

[dblaikie]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

974

Naively, it looks to me like this API change would allow for emission of debug_frame and eh_frame simultaneously. Is that understanding correct? If it is, is that outcome useful/intended? I'd have thought one or the other would suffice? (if you have eh_frame and its drawback of being ALLOC - you don't gain anything by also emmitting debug_frame, do you?)

[scott.linder]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

974

Yes, that's correct. It is still NFC, as that was the behavior before, it just wasn't represented here. See below:

else if (Asm->TM.Options.ForceDwarfFrameSection)
      Asm->OutStreamer->emitCFISections(true, true);

IIRC this was the confusion that led me to the refactoring to begin with. It also generalizes isCFIMoveForDebugging and documents what it actually is.

As to whether it makes sense to emit both, I don't know, but it is intended (emphasis mine):

In D67216#1705839, @dcandler wrote:

I've modified the patch so that the new flag will ensure the cfi instructions are actually present to be emitted as well. I went ahead and renamed the flag -gdwarf-frame too, to better reflect that it's dealing with the debug information you'd otherwise get with -g, and is meant to specifically put the information in a .debug_frame section and not .eh_frame.

Currently, two things signal for need for cfi: exceptions (via the function's needsUnwindTableEntry()), and debug (via the machine module information's hasDebugInfo()). At frame lowering, both trigger the same thing. But when the assembly printer decides on which section to use, needsUnwindTableEntry() is checked first and triggers the need for .eh_frame, while hasDebugInfo() is checked afterwards for whether .debug_frame is needed. So .debug_frame is only present when any level of debug is requested, and no functions need unwinding for exceptions.

It wouldn't be appropriate to change either needsUnwindTableEntry() or hasDebugInfo(), so I've added a check for my flag alongside them. Because the same logic is used in multiple places, I've wrapped all three checks into one function to try and clean things up slightly. When deciding on which section to emit, the new flag means .debug_frame is produced instead of nothing. If .eh_frame would have been needed, rather than replace it, the new flag simply emits both .debug_frame and .eh_frame.

The end result is that -gdwarf-frame should only provide a .debug_frame section as additional information, without otherwise modifying anything. The existing -funwind-tables (and -fasynchronous-unwind-tables) flag can be used to provide similar information, but because it takes the exception angle, it alters function attributes and ultimately produces .eh_frame instead.

[MaskRay]

The refactoring makes sense (did not notice that it was posted a couple of months ago!) . This dropped a confusing isCFIMoveForDebugging and removed the following block which confused me a bit.

for (auto &F: M.getFunctionList()) {
      // If the module contains any function with unwind data,
      // .eh_frame has to be emitted.
      // Ignore functions that won't get emitted.
      if (!F.isDeclarationForLinker() && F.needsUnwindTableEntry()) {
        isCFIMoveForDebugging = false;
        break;
      }
    }

As a potential follow-up, I do want the CFIMoveTypes concept to be better documented and probably rename it if it does not convey the intended meaning to readers.

The code does allow both sections due to ForceDwarfFrameSection. Please give some time to @dblaikie who has commented.

[dblaikie]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

974

Sorry, I don't have enough context here, so it's still a bit confusing:

"It is still NFC, as that was the behavior before, it just wasn't represented here. " - you're saying that prior to this patch/currently in LLVM, it was possible that both eh_frame and debug_frame were emitted into the same output file? (is that a useful thing? why is that supported?)

@dcandler @ostannard - do you folks have some context you could share here?

But, at least as far as the immediate/blocking issues for this current proposed patch are concerned - yeah, I guess this API change clarifies the existing behavior/intent. Thanks!

[scott.linder]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

974

Sorry, I don't have enough context here, so it's still a bit confusing:

"It is still NFC, as that was the behavior before, it just wasn't represented here. " - you're saying that prior to this patch/currently in LLVM, it was possible that both eh_frame and debug_frame were emitted into the same output file?

Correct, for example:

~/code/llvm-project:main$ git show --no-patch --oneline
d5700fdf1045 (HEAD -> main, origin/master, origin/main, origin/HEAD) [gn build] Port 6eff12788ee
~/code/llvm-project:main$ echo 'void f() {}' | release/bin/clang -x c - -fforce-dwarf-frame -S -o - | grep cfi_sections
        .cfi_sections .eh_frame, .debug_frame
~/code/llvm-project:main$ echo 'void f() {}' | release/bin/clang -x c - -fforce-dwarf-frame -c -o - | release/bin/llvm-dwarfdump -debug-frame - | grep -A5 contents
.debug_frame contents:

00000000 00000014 ffffffff CIE
  Format:                DWARF32
  Version:               4
  Augmentation:          ""
--
.eh_frame contents:

00000000 00000014 00000000 CIE
  Format:                DWARF32
  Version:               1
  Augmentation:          "zR"

(is that a useful thing? why is that supported?)

The first thing that comes to my mind is if you have a language runtime which requires .eh_frame (i.e. for EH) and some other tool which only understands .debug_frame. The runtime cannot use .debug_frame (or I suppose it could if it were marked ALLOC and the runtime were willing to do some more relocation), and the tool would have to be taught how to use .eh_frame (this seems reasonable, but so does just putting in both tables). It would be convenient in that case to just emit both.

To answer the converse question of "is it useful to forbid this? why would we not support this?" I would say that it might cause confusion (both for users and for tools), the tables may somehow disagree (although that seems like it would constitute a bug in LLVM), and it adds some amount of complexity in that we are changing an enum of mutually exclusive things to orthogonal flags.

@dcandler @ostannard - do you folks have some context you could share here?

But, at least as far as the immediate/blocking issues for this current proposed patch are concerned - yeah, I guess this API change clarifies the existing behavior/intent. Thanks!

974

Sorry, I don't have enough context here, so it's still a bit confusing:

"It is still NFC, as that was the behavior before, it just wasn't represented here. " - you're saying that prior to this patch/currently in LLVM, it was possible that both eh_frame and debug_frame were emitted into the same output file? (is that a useful thing? why is that supported?)

@dcandler @ostannard - do you folks have some context you could share here?

But, at least as far as the immediate/blocking issues for this current proposed patch are concerned - yeah, I guess this API change clarifies the existing behavior/intent. Thanks!

974

Whoops, I must have hit reply twice; disregard this response.

[RamNalamothu]

In D76519#2452608, @MaskRay wrote:

As a potential follow-up, I do want the CFIMoveTypes concept to be better documented and probably rename it if it does not convey the intended meaning to readers.

Since the AsmPrinter essentially consumes the CFI instructions and emits the parsed information, in DWARF CFI format, into either .debug_frame or .eh_frame or both, I think may be it makes sense to rename CFIMoveTypes on the following lines?

// Flags representing which section, containing DWARF CFI unwind information, to be generated i.e. .eh_frame or .debug_frame.
  enum CFIUnwindSection : unsigned { CFI_None = 0, CFI_EH_Frame = 1, CFI_Debug_Frame = 2 };

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

974

Naively, it looks to me like this API change would allow for emission of debug_frame and eh_frame simultaneously. Is that understanding correct? If it is, is that outcome useful/intended? I'd have thought one or the other would suffice? (if you have eh_frame and its drawback of being ALLOC - you don't gain anything by also emmitting debug_frame, do you?)

Yes, both .eh_frame and .debug_frame can be emitted into the same output file. AFAIU this ability is primarily needed for the following reasons.

1. PowerPC uses different register numbering in .debug_frame and .eh_frame. I think, this is (one of) the reason why GCC also has the capability to generate both .eh_frame and .debug_frame into the same output file.

2. Erstwhile LLVM toolchain used the system assembler/linker, typically the GCC's assembler/linker, and also I think the LLVM's assembler/linker strives to be a drop in replacement for GCC ones. And this naturally forces LLVM to support GAS assembler directives and their syntax.

3. A strict DWARF compliant debugger needs .debug_frame which doesn't have exception handling features and this forces generating .eh_frame as well if we also need exception handling support in those cases.

[RamNalamothu]

Scott, I will take this forward. Hope that is fine.

[RamNalamothu]

Renaming the state variables for better representation.

[RamNalamothu]

Does it look better now, after the renaming?

[MaskRay]

Refactor how CFI move sections

Since 'move' is coined term which is not accurate, just avoid using it.

Can you rephrase why we need both .eh_frame & .debug_frame?

See also D100251. The logic here is subtle. I enumerate {-g,-g0} x {-fno-exceptions,-fexceptions} x {-fno-asynchronous-unwind-tables,-fasynchronous-unwind-tables} and compare the result with GCC to ensure the behaviors are reasonable.

llvm/include/llvm/CodeGen/AsmPrinter.h

213

Just use CFISection. You can consider enum class.

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

982–986

Drop braces around one-line simple statements.

[RamNalamothu]

Address review comments.

[RamNalamothu]

In D76519#2714352, @MaskRay wrote:

Refactor how CFI move sections

Since 'move' is coined term which is not accurate, just avoid using it.

Ah, I had fixed it in the commit message but not on Phabricator.

Can you rephrase why we need both .eh_frame & .debug_frame?

Capability of emitting both sections was already there and this patch just maintained the status quo.

Probably the following was adding the confusion. I have changed it little bit in the latest diff update.

/// Cached bitwise OR of CFISection flags for all functions in the module.
unsigned ModuleCFISections = CFISection::None;

And on why emit both sections, as it was mentioned earlier also, this is all that comes to my mind.

In D67216#1705839, @dcandler wrote:
I've modified the patch so that the new flag will ensure the cfi instructions are actually present to be emitted as well. I went ahead and renamed the flag -gdwarf-frame too, to better reflect that it's dealing with the debug information you'd otherwise get with -g, and is meant to specifically put the information in a .debug_frame section and not .eh_frame.

Currently, two things signal for need for cfi: exceptions (via the function's needsUnwindTableEntry()), and debug (via the machine module information's hasDebugInfo()). At frame lowering, both trigger the same thing. But when the assembly printer decides on which section to use, needsUnwindTableEntry() is checked first and triggers the need for .eh_frame, while hasDebugInfo() is checked afterwards for whether .debug_frame is needed. So .debug_frame is only present when any level of debug is requested, and no functions need unwinding for exceptions.

It wouldn't be appropriate to change either needsUnwindTableEntry() or hasDebugInfo(), so I've added a check for my flag alongside them. Because the same logic is used in multiple places, I've wrapped all three checks into one function to try and clean things up slightly. When deciding on which section to emit, the new flag means .debug_frame is produced instead of nothing. If .eh_frame would have been needed, rather than replace it, the new flag simply emits both .debug_frame and .eh_frame.

The end result is that -gdwarf-frame should only provide a .debug_frame section as additional information, without otherwise modifying anything. The existing -funwind-tables (and -fasynchronous-unwind-tables) flag can be used to provide similar information, but because it takes the exception angle, it alters function attributes and ultimately produces .eh_frame instead.

@scott.linder wrote:
The first thing that comes to my mind is if you have a language runtime which requires .eh_frame (i.e. for EH) and some other tool which only understands .debug_frame. The runtime cannot use .debug_frame (or I suppose it could if it were marked ALLOC and the runtime were willing to do some more relocation), and the tool would have to be taught how to use .eh_frame (this seems reasonable, but so does just putting in both tables). It would be convenient in that case to just emit both.

@RamNalamothu wrote:
Yes, both .eh_frame and .debug_frame can be emitted into the same output file. AFAIU this ability is primarily needed for the following reasons.

1. PowerPC uses different register numbering in .debug_frame and .eh_frame. I think, this is (one of) the reason why GCC also has the capability to generate both .eh_frame and .debug_frame into the same output file.

2. Erstwhile LLVM toolchain used the system assembler/linker, typically the GCC's assembler/linker, and also I think the LLVM's assembler/linker strives to be a drop in replacement for GCC ones. And this naturally forces LLVM to support GAS assembler directives and their syntax.

3. A strict DWARF compliant debugger needs .debug_frame which doesn't have exception handling features and this forces generating .eh_frame as well if we also need exception handling support in those cases.

[MaskRay]

LG!

[MaskRay]

I noticed that this is not quite NFC. In ThinLTO this may change .eh_frame output to .debug_frame output. I'll need to look more closely.

[MaskRay]

I am sorry but I reverted this in e01c666b136e3f97587b22a2029f31e5c36a0e71.

D76519 was not quite NFC. If we see a CFISection::Debug function before a
CFISection::EH one (-fexceptions -fno-asynchronous-unwind-tables), we may
incorrectly pick CFISection::Debug and emit a `.cfi_sections .debug_frame`.
We should use .eh_frame instead.

[MaskRay]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

327–328

ModuleCFISection = getFunctionCFISectionType(F);
if (ModuleCFISection == AsmPrinter::CFISection::EH)
  break;

[RamNalamothu]

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

327–328

Ah!

ModuleCFISection = getFunctionCFISectionType(F);
if (ModuleCFISection == AsmPrinter::CFISection::EH)
  break;

But wouldn't this give incorrect results if we see CFISection::Debug first and then a CFISection::None function as the last one i.e. without a CFISection::EH in between?
That is what I was trying to avoid in my original patch.

May be the following is a better one?

if (ModuleCFISection == AsmPrinter::CFISection::EH)
  break;

if (getFunctionCFISectionType(F) != AsmPrinter::CFISection::None)
  ModuleCFISection = getFunctionCFISectionType(F);

[RamNalamothu]

Address review comments.

[MaskRay]

Thanks!

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

327–328

If you reorder if (ModuleCFISection == CFISection::EH) after if (getFunctionCFISectionType(F) != CFISection::None), the loop will exit in the same iteration, not the next iteration.

[RamNalamothu]

Implemented the suggested improvement.

llvm/include/llvm/CodeGen/AsmPrinter.h

 public:
   struct SrcMgrDiagInfo {
     SourceMgr SrcMgr;
     std::vector<const MDNode *> LocInfos;
     LLVMContext::InlineAsmDiagHandlerTy DiagHandler;
     void *DiagContext;
   };
 
+  // Flags representing what CFI move sections are required for a function.
+  enum CFIMoveType : unsigned { CFI_M_None = 0, CFI_M_EH = 1, CFI_M_Debug = 2 };
+
 private:
   /// If generated on the fly this own the instance.
   std::unique_ptr<MachineDominatorTree> OwnedMDT;
 
   /// If generated on the fly this own the instance.
   std::unique_ptr<MachineLoopInfo> OwnedMLI;
 
   /// Structure for generating diagnostics for inline assembly. Only initialised
   /// when necessary.
   mutable std::unique_ptr<SrcMgrDiagInfo> DiagInfo;
 
   /// If the target supports dwarf debug info, this pointer is non-null.
   DwarfDebug *DD = nullptr;
 
-  /// If the current module uses dwarf CFI annotations strictly for debugging.
-  bool isCFIMoveForDebugging = false;
+  /// Cached bitwise OR of CFIMoveType flags for all functions in the module.
+  unsigned ModuleCFIMoveTypes = CFI_M_None;
 
 protected:
   explicit AsmPrinter(TargetMachine &TM, std::unique_ptr<MCStreamer> Streamer);
 
 public:
   ~AsmPrinter() override;
 
   DwarfDebug *getDwarfDebug() { return DD; }
public:
   void emitFrameAlloc(const MachineInstr &MI);
 
   void emitStackSizeSection(const MachineFunction &MF);
 
   void emitBBAddrMapSection(const MachineFunction &MF);
 
   void emitRemarksSection(remarks::RemarkStreamer &RS);
 
-  enum CFIMoveType { CFI_M_None, CFI_M_EH, CFI_M_Debug };
-  CFIMoveType needsCFIMoves() const;
-
-  /// Returns false if needsCFIMoves() == CFI_M_EH for any function
-  /// in the module.
-  bool needsOnlyDebugCFIMoves() const { return isCFIMoveForDebugging; }
+  /// Get the CFIMoveType flags for a function.
+  unsigned getCFIMoveTypes(const Function &F) const;
+  /// Get the CFIMoveType flags for a function.
+  unsigned getCFIMoveTypes(const MachineFunction &MF) const;
+  /// Get the bitwise OR of CFIMoveType flags for all functions in the module.
+  unsigned getCFIMoveTypes() const { return ModuleCFIMoveTypes; }
 
   bool needsSEHMoves();
 
   /// Print to the current output stream assembly representations of the
   /// constants in the constant pool MCP. This is used to print out constants
   /// which have been "spilled to memory" by the code generator.
   virtual void emitConstantPool();
 

llvm/lib/CodeGen/AsmPrinter/ARMException.cpp

ARMTargetStreamer &ARMException::getTargetStreamer() {
   MCTargetStreamer &TS = *Asm->OutStreamer->getTargetStreamer();
   return static_cast<ARMTargetStreamer &>(TS);
 }
 
 void ARMException::beginFunction(const MachineFunction *MF) {
   if (Asm->MAI->getExceptionHandlingType() == ExceptionHandling::ARM)
     getTargetStreamer().emitFnStart();
   // See if we need call frame info.
-  AsmPrinter::CFIMoveType MoveType = Asm->needsCFIMoves();
-  assert(MoveType != AsmPrinter::CFI_M_EH &&
+  unsigned MoveTypes = Asm->getCFIMoveTypes(*MF);
+  assert(!(MoveTypes & AsmPrinter::CFI_M_EH) &&
          "non-EH CFI not yet supported in prologue with EHABI lowering");
 
-  if (MoveType == AsmPrinter::CFI_M_Debug) {
+  if (MoveTypes & AsmPrinter::CFI_M_Debug) {
     if (!hasEmittedCFISections) {
-      if (Asm->needsOnlyDebugCFIMoves())
-        Asm->OutStreamer->emitCFISections(false, true);
       hasEmittedCFISections = true;
     }
 
     shouldEmitCFI = true;
     Asm->OutStreamer->emitCFIStartProc(false);
   }
 }
 

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp

if (!EmitCodeView || M.getDwarfVersion()) {
                             DbgTimerDescription, DWARFGroupName,
                             DWARFGroupDescription);
     }
   }
 
   switch (MAI->getExceptionHandlingType()) {
   case ExceptionHandling::SjLj:
   case ExceptionHandling::DwarfCFI:
   case ExceptionHandling::ARM:
-    isCFIMoveForDebugging = true;
-    if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)
-      break;
-    for (auto &F: M.getFunctionList()) {
-      // If the module contains any function with unwind data,
-      // .eh_frame has to be emitted.
-      // Ignore functions that won't get emitted.
-      if (!F.isDeclarationForLinker() && F.needsUnwindTableEntry()) {
-        isCFIMoveForDebugging = false;
-        break;
-      }
-    }
+    for (auto &F : M.getFunctionList())
+      ModuleCFIMoveTypes |= getCFIMoveTypes(F);
+    assert(MAI->getExceptionHandlingType() == ExceptionHandling::DwarfCFI ||
+           !(ModuleCFIMoveTypes & CFI_M_EH));
     break;
   default:
-    isCFIMoveForDebugging = false;
     break;
   }
 
   EHStreamer *ES = nullptr;
   switch (MAI->getExceptionHandlingType()) {
   case ExceptionHandling::None:
     break;
   case ExceptionHandling::SjLj:
static bool emitDebugLabelComment(const MachineInstr *MI, AsmPrinter &AP) {
   }
   OS << V->getName();
 
   // NOTE: Want this comment at start of line, don't emit with AddComment.
   AP.OutStreamer->emitRawComment(OS.str());
   return true;
 }
 
-AsmPrinter::CFIMoveType AsmPrinter::needsCFIMoves() const {
+unsigned AsmPrinter::getCFIMoveTypes(const Function &F) const {
+  // Ignore functions that won't get emitted.
+  if (F.isDeclarationForLinker())
+    return CFI_M_None;
+
+  unsigned Type = CFI_M_None;
+
   if (MAI->getExceptionHandlingType() == ExceptionHandling::DwarfCFI &&
-      MF->getFunction().needsUnwindTableEntry())
-    return CFI_M_EH;
+      F.needsUnwindTableEntry()) {
+    Type |= CFI_M_EH;
+  } else if (MMI->hasDebugInfo()) {
+    Type |= CFI_M_Debug;
+  }
 
-  if (MMI->hasDebugInfo() || MF->getTarget().Options.ForceDwarfFrameSection)
-    return CFI_M_Debug;
+  if (TM.Options.ForceDwarfFrameSection)
+    Type |= CFI_M_Debug;
 
-  return CFI_M_None;
+  return Type;
+}
+
+unsigned AsmPrinter::getCFIMoveTypes(const MachineFunction &MF) const {
+  return getCFIMoveTypes(MF.getFunction());
 }
 
 bool AsmPrinter::needsSEHMoves() {
   return MAI->usesWindowsCFI() && MF->getFunction().needsUnwindTableEntry();
 }
 
 void AsmPrinter::emitCFIInstruction(const MachineInstr &MI) {
   ExceptionHandling ExceptionHandlingType = MAI->getExceptionHandlingType();
   if (ExceptionHandlingType != ExceptionHandling::DwarfCFI &&
       ExceptionHandlingType != ExceptionHandling::ARM)
     return;
 
-  if (needsCFIMoves() == CFI_M_None)
+  if (getCFIMoveTypes(*MF) == CFI_M_None)
     return;
 
   // If there is no "real" instruction following this CFI instruction, skip
   // emitting it; it would be beyond the end of the function's FDE range.
   auto *MBB = MI.getParent();
   auto I = std::next(MI.getIterator());
   while (I != MBB->end() && I->isTransient())
     ++I;

llvm/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp

 void DwarfCFIException::beginFunction(const MachineFunction *MF) {
   shouldEmitMoves = shouldEmitPersonality = shouldEmitLSDA = false;
   const Function &F = MF->getFunction();
 
   // If any landing pads survive, we need an EH table.
   bool hasLandingPads = !MF->getLandingPads().empty();
 
   // See if we need frame move info.
-  AsmPrinter::CFIMoveType MoveType = Asm->needsCFIMoves();
-
-  shouldEmitMoves = MoveType != AsmPrinter::CFI_M_None;
+  shouldEmitMoves = Asm->getCFIMoveTypes(*MF) != AsmPrinter::CFI_M_None;
 
   const TargetLoweringObjectFile &TLOF = Asm->getObjFileLowering();
   unsigned PerEncoding = TLOF.getPersonalityEncoding();
   const Function *Per = nullptr;
   if (F.hasPersonalityFn())
     Per = dyn_cast<Function>(F.getPersonalityFn()->stripPointerCasts());
 
   // Emit a personality function even when there are no landing pads

 }
 
 void DwarfCFIException::beginFragment(const MachineBasicBlock *MBB,
                                       ExceptionSymbolProvider ESP) {
   if (!shouldEmitCFI)
     return;
 
   if (!hasEmittedCFISections) {
-    if (Asm->needsOnlyDebugCFIMoves())
-      Asm->OutStreamer->emitCFISections(false, true);
-    else if (Asm->TM.Options.ForceDwarfFrameSection)
-      Asm->OutStreamer->emitCFISections(true, true);
+    unsigned MoveTypes = Asm->getCFIMoveTypes();
+    // If we don't say anything it implies `.cfi_sections .eh_frame`, so we
+    // chose not to be verbose in that case.
+    if (MoveTypes & AsmPrinter::CFI_M_Debug)
+      Asm->OutStreamer->emitCFISections(MoveTypes & AsmPrinter::CFI_M_EH,
+                                        MoveTypes & AsmPrinter::CFI_M_Debug);
     hasEmittedCFISections = true;
   }
 
   Asm->OutStreamer->emitCFIStartProc(/*IsSimple=*/false);
 
   // Indicate personality routine, if any.
   if (!shouldEmitPersonality)
     return;

llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp

case AArch64::DBG_VALUE: {
     return;
 
   case AArch64::EMITBKEY: {
       ExceptionHandling ExceptionHandlingType = MAI->getExceptionHandlingType();
       if (ExceptionHandlingType != ExceptionHandling::DwarfCFI &&
           ExceptionHandlingType != ExceptionHandling::ARM)
         return;
 
-      if (needsCFIMoves() == CFI_M_None)
+      if (getCFIMoveTypes(*MF) == CFI_M_None)
         return;
 
       OutStreamer->emitCFIBKeyFrame();
       return;
     }
   }
 
   // Tail calls use pseudo instructions so they have the proper code-gen