[MC] Omit DWARF unwind info if compact unwind is present where eligible

[int3]

Summary

Previously, omitting unnecessary DWARF unwinds was only done in two
cases:

• For Darwin + aarch64, if no DWARF unwind info is needed for all the functions in a TU, then the __eh_frame section would be omitted entirely. If any one function needed DWARF unwind, then MC would emit DWARF unwind entries for all the functions in the TU.
• For watchOS, MC would omit DWARF unwind on a per-function basis, as long as compact unwind was available for that function.

This diff makes it so that we omit DWARF unwind on a per-function basis
for Darwin + aarch64 as well. In addition, we introduce the flag
--emit-dwarf-unwind= which can toggle between always,
no-compact-unwind (only emit DWARF when CU cannot be emitted for a
given function), and the target platform default. no-compact-unwind
is particularly useful for newer x86_64 platforms: we don't want to omit
DWARF unwind for x86_64 in general due to possible backwards compat
issues, but we should make it possible for people to opt into this
behavior if they are only targeting newer platforms.

Motivation: I'm working on adding support for __eh_frame to LLD,
but I'm concerned that we would suffer a perf hit. Processing compact
unwind is already expensive, and that's a simpler format than EH frames.
Given that MC currently produces one EH frame entry for every compact
unwind entry, I don't think processing them will be cheap. I tried to do
something clever on LLD's end to drop the unnecessary EH frames at parse
time, but this made the code significantly more complex. So I'm looking
at fixing this at the MC level instead.

Addendum: It turns out that there was a latent bug in the X86
backend when OmitDwarfIfHaveCompactUnwind is naively enabled, which is
not too surprising given that this combination has not been heretofore
used.

For functions that have unwind info that cannot be encoded with CU, MC
would end up dropping both the compact unwind entry (OK; existing
behavior) as well as the DWARF entries (not OK). This diff fixes things
so that we emit the DWARF entry, as well as a CU entry with encoding
UNWIND_X86_MODE_DWARF -- this basically tells the unwinder to look for
the DWARF entry. I'm not 100% sure the UNWIND_X86_MODE_DWARF CU entry
is necessary, this was the simplest fix. ld64 seems to be able to handle
both the absence and presence of this CU entry. Ultimately ld64 (and
LLD) will synthesize UNWIND_X86_MODE_DWARF if it is absent, so there
is no impact to the final binary size.

[MaskRay]

Previously, omitting unnecessary DWARF unwinds was only done for watchOS,

I have looked at compact unwind descriptors in 2020-11 to write https://maskray.me/blog/2020-11-08-stack-unwinding#compact-unwind-descriptors
I vaguely remember there is a place where DWARF unwind info is enabled for all but few environments (like watchOS). Where is it?
My conjecture is that it may be related to the fact that the compact unwind descriptor does not support async unwind tables well and there may be cases needing it.

[int3]

llvm/lib/MC/MCObjectFileInfo.cpp

66–67

@MaskRay

I vaguely remember there is a place where DWARF unwind info is enabled for all but few environments (like watchOS). Where is it?

here :)

[lhames]

I'm currently doing that via MCContext::getGenDwarfForAssembly...

This isn't my wheelhouse, but at first glance GenDwarfForAssembly looks like it might control all Dwarf sections (including debug ones). If that's the case you might need to introduce something eh-frame specific.

Previously, omitting unnecessary DWARF unwinds was only done for
watchOS, but I've heard that it might be possible to do this for all
archs.

Sounds like this was for bincompat with older unwinders when compact-unwind was first released. I think we can turn this off by default now.

I believe the root cause is that libunwind is unable to load compact
unwind dynamically. (I believe this limitation applies not just to MCJIT but to
ORC and the regular interpreter as well -- @lhames, would you be able to
confirm?)

That's right. Adding dynamic registration for compact unwind is pretty high on my todo list. I'm hoping to get to it within the next month or so. We should still have a way to force eh-frames though.

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

48

I guess this is just a placeholder? The final commit should include more detail.

llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp

131–132

Is this needed? With your change, registerEHFramesInProcess should be a no-op if Size == 0.

llvm/tools/llc/llc.cpp

697–700

This option hand-off feels very manual. I wonder if we should add a propagateTargetOptionsToMC function, but maybe the set of options that it would apply to is small enough not to bother for now?

I would add something like this to LLVMTargetMachine::addPassesToEmitMC too, for the the case where the caller passes in a null MCContext*.

[int3]

I'm currently working on the eh_frame support in LLD itself, but will circle back to this diff in a week or so. Thanks for the feedback!

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

48

yep, just a placeholder

llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp

131–132

might not be yeah. I wasn't sure whether the extra entry in EHFrames would be an issue, but I will double check

llvm/tools/llc/llc.cpp

697–700

thanks for the pointers! I'll look into that

[int3]

llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp

131–132

looks like it isn't necessary. removing

llvm/tools/llc/llc.cpp

697–700

actually, I'm not sure I understood your suggestion... which class do you envision propagateTargetOptionsToMC being defined in? How would it make things "less manual"?

[int3]

• Use a separate ForceDwarfUnwindInfo flag
• Fix the remaining tests

[int3]

This is ready for review, please take a look 🙏

[int3]

fix x86 backend's omission of DWARF unwind

[int3]

bump @lhames @JDevlieghere would either of y'all be able to review this?

[lhames]

llvm/tools/llc/llc.cpp

697–700

Oh! TargetOptions has an MCTargetOptions member already. If GenDwarfUnwindInfo === ForceDwarfUnwindInfo, could you just sink ForceDwarfUnwindInfo into MCTargetOptions?

[int3]

use MCTargetOptions

[int3]

llvm/lib/CodeGen/MachineModuleInfo.cpp

69 ↗

(On Diff #425408)

MCTargetOptions isn't passed directly to MCObjectFileInfo; it only gets an MCContext. MCContext already has a member pointer to MCTargetOptions, but it seemed not to be initialized in a number of cases, hence the need for this change.

llvm/tools/llc/llc.cpp

697–700

alright, I think I got it to work :)

[davide]

Compact unwind was developed as a goal to replace the DWARF unwind. Some apps did not work if the OS was missing DWARF unwind, so we kept both for Intel. The binary compatibility issue is non-existent on arm64, but it could be still a thing on x86_64.
If a function cannot be encoded in CU, we need the compiler to emit both (where the CU is a magic value that points to the dwarf unwind info for that function).

tl;dr: this is "a nice cleanup", and potentially the bincompat issue might be gone, but the cost of breaking programs in the wild is IMHO too high.

[int3]

Thanks for the feedback!

The binary compatibility issue is non-existent on arm64, but it could be still a thing on x86_64.

Can we enable OmitDwarfIfHaveCompactUnwind by default on arm64 then? And have it be opt-in just for x86_64?

[davide]

In D122258#3479045, @int3 wrote:

Thanks for the feedback!

The binary compatibility issue is non-existent on arm64, but it could be still a thing on x86_64.

Can we enable OmitDwarfIfHaveCompactUnwind by default on arm64 then? And have it be opt-in just for x86_64?

I think it's fine.

[davide]

LGTM

[int3]

add --no-force-dwarf-unwind-info; only omit by default on aarch64

[int3]

update

[int3]

update

[int3]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

this code doesn't execute if clang is passed an assembly file instead of a .c file, so this option doesn't have the desired effect on assembly inputs. I'm not sure what's the right way to tackle this, or if this behavior inconsistency is acceptable

[smeenai]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

It seems unfortunate to have that inconsistency. From what I can tell, clang/tools/driver/cc1as_main.cpp looks like it might be the rough equivalent of this for the integrated assembler?

[int3]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

that's what I'd thought too, but I set a breakpoint on cc1as_main & ExecuteAssemblerImpl and then ran clang -c foo.s; neither breakpoint triggered

[smeenai]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

Hmm, interesting. If you run with -###, is -cc1as being invoked in-process or out of process? Idk if the in-process cc1as has a different entry point.

[smeenai]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

Nah, looks like in-process cc1as should be calling cc1as_main as well: https://github.com/llvm/llvm-project/blob/98616cfc02613d98964588fac6494ec7583c495f/clang/tools/driver/driver.cpp#L319

(If it's out of process you'd need to debug the cc1as process and not the driver process, of course, but I'd be surprised if you end up with an out of process cc1as)

[int3]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

ah yeah I guess that's it. I'd enabled settings set target.process.follow-fork-mode child but that doesn't seem to have the desired effect; but modifying cc1as_main itself shows that it is indeed being called.

[int3]

make things work under cc1as too

[int3]

clang/lib/CodeGen/BackendUtil.cpp

456 ↗

(On Diff #427398)

alright this works now, thanks for the pointers!

clang/tools/driver/cc1as_main.cpp

323 ↗

(On Diff #427509)

this is a bit of code duplication, but the same approach is used to have OPT_fembed_bitcode_EQ accepted by both the integrated assembler as will as the CompilerInvocation.

[int3]

Buildbots gave me a bunch of errors of the form

/home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/llvm-mc: error: unable to get target for 'arm64-apple-macos11.0', see --version and --triple.

I'm wondering if I'm just missing a REQUIRES line, but then again I don't see any other tests under MC/MachO that use REQUIRES...

Or should I be using darwin instead of macos? Does it matter?

[thakis]

I think it should work if you put the test in llvm/test/MC/MachO/AArch64 instead of in llvm/test/MC/MachO, because of:

% cat llvm/test/MC/MachO/AArch64/lit.local.cfg 
if not 'AArch64' in config.root.targets:
    config.unsupported = True

[int3]

d'oh, I see it now. And of course the parent llvm/test/MC/MachO directory is gated to x86-only. Thanks!

[uabelho]

Hi,

I noticed that on one of our downstream (not public) buildbots the

clang/test/Driver/femit-dwarf-unwind.s

test seems to fail rather randomly.
So if I run

clang -target x86_64-apple-macos11.0 -c ../clang/test/Driver/femit-dwarf-unwind.s -o foo.o
llvm-objdump --macho --dwarf=frames foo.o

a couple of times I sometimes get

.debug_frame contents:


.eh_frame contents:

and sometimes I get

.debug_frame contents:


.eh_frame contents:

00000000 00000014 00000000 CIE
  Format:                DWARF32
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     10

  DW_CFA_def_cfa: reg7 +8
  DW_CFA_offset: reg16 -8
  DW_CFA_nop:
  DW_CFA_nop:

  CFA=reg7+8: reg16=[CFA-8]

00000018 0000001c 0000001c FDE cie=00000000 pc=00000000...00000001
  Format:       DWARF32
  DW_CFA_def_cfa_offset: +8
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:
  DW_CFA_nop:

  0x0: CFA=reg7+8: reg16=[CFA-8]

On another machine I don't seem to get that problem though, even if I compile in the same way so I really don't know what the difference is or why it is happening at all.
Any ideas? Anything anyone else is seeing?

EDIT:
If I add

-femit-dwarf-unwind=default

it seems to pass all the time, so I don't know if the problem is that the -femit-dwarf-unwind flag doesn't get a proper default value if not set explicitly?

[int3]

Oh dear. Hmm does running the test with ASAN enabled hit any memory issues?

[int3]

Actually let me try it now

[int3]

clang/tools/driver/cc1as_main.cpp

323–329 ↗

(On Diff #436220)

still building ASAN but this looks sus -- if no flag gets passed, we never initialize EmitDwarfUnwind before using it on line 381

also it occurred to me that if the buildbots haven't flagged anything, ASAN probably can't detect this. Let me just put up a patch

[uabelho]

clang/tools/driver/cc1as_main.cpp

323–329 ↗

(On Diff #436220)

We have bots running ASAN on this without complaining.

A patch sounds good! Thanks!

[thakis]

In D122258#3478727, @davide wrote:

Compact unwind was developed as a goal to replace the DWARF unwind. Some apps did not work if the OS was missing DWARF unwind, so we kept both for Intel. The binary compatibility issue is non-existent on arm64, but it could be still a thing on x86_64.
If a function cannot be encoded in CU, we need the compiler to emit both (where the CU is a magic value that points to the dwarf unwind info for that function).

tl;dr: this is "a nice cleanup", and potentially the bincompat issue might be gone, but the cost of breaking programs in the wild is IMHO too high.

Do you think clang could enable it by default even on intel if the deployment target is "new enough"?

[jyknight]

no-compact-unwind is particularly useful for newer x86_64 platforms: we don't want to omit DWARF unwind for x86_64 in general due to possible backwards compat issues, but we should make it possible for people to opt into this behavior if they are only targeting newer platforms.

Shouldn't we make default imply no-compact-unwind when the target triple OS version is high enough? (Compact-unwind was added in macOS 10.6, correct? That's lower than anyone realistically targets these days...)

clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp

createInterpreter(const Args &ExtraArgs = {},
   Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
   ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
   auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
   if (Client)
     CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
   return cantFail(clang::Interpreter::create(std::move(CI)));
 }
 
+// FIXME
 TEST(InterpreterTest, CatchException) {
   llvm::InitializeNativeTarget();
   llvm::InitializeNativeTargetAsmPrinter();
 
   {
     auto J = llvm::orc::LLJITBuilder().create();
     if (!J) {
       // The platform does not support JITs.

llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp

 #include "llvm/ExecutionEngine/ObjectCache.h"
 #include "llvm/ExecutionEngine/SectionMemoryManager.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/DerivedTypes.h"
 #include "llvm/IR/Function.h"
 #include "llvm/IR/LegacyPassManager.h"
 #include "llvm/IR/Mangler.h"
 #include "llvm/IR/Module.h"
+#include "llvm/MC/MCContext.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Object/ObjectFile.h"
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/SmallVectorMemoryBuffer.h"
 #include <mutex>
 
std::unique_ptr<MemoryBuffer> MCJIT::emitObject(Module *M) {
   // generateCodeForModule.
 
   legacy::PassManager PM;
 
   // The RuntimeDyld will take ownership of this shortly
   SmallVector<char, 4096> ObjBufferSV;
   raw_svector_ostream ObjStream(ObjBufferSV);
 
+  if (Ctx)
+    Ctx->setGenDwarfForAssembly(true);
   // Turn the machine code intermediate representation into bytes in memory
   // that may be executed.
   if (TM->addPassesToEmitMC(PM, Ctx, ObjStream, !getVerifyModules()))
     report_fatal_error("Target does not support MC emission!");
 
   // Initialize passes.
   PM.run(*M);
   // Flush the output buffer to get the generated code into memory

llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp

 // and use the LoadAddr parameter.
 void RTDyldMemoryManager::registerEHFramesInProcess(uint8_t *Addr,
                                                     size_t Size) {
   // On OS X OS X __register_frame takes a single FDE as an argument.
   // See http://lists.llvm.org/pipermail/llvm-dev/2013-April/061737.html
   // and projects/libunwind/src/UnwindLevel1-gcc-ext.c.
   const char *P = (const char *)Addr;
   const char *End = P + Size;
-  do  {
+  while (P != End)
     P = processFDE(P, false);
-  } while(P != End);
 }
 
 void RTDyldMemoryManager::deregisterEHFramesInProcess(uint8_t *Addr,
                                                       size_t Size) {
   const char *P = (const char *)Addr;
   const char *End = P + Size;
-  do  {
+  while (P != End)
     P = processFDE(P, true);
-  } while(P != End);
 }
 
 #else
 
 void RTDyldMemoryManager::registerEHFramesInProcess(uint8_t *Addr,
                                                     size_t Size) {
   // On Linux __register_frame takes a single argument:
   // a pointer to the start of the .eh_frame section.
 
   // How can it find the end? Because crtendS.o is linked
   // in and it has an .eh_frame section with four zero chars.
   __register_frame(Addr);
 }
 
 void RTDyldMemoryManager::deregisterEHFramesInProcess(uint8_t *Addr,
                                                       size_t Size) {
   __deregister_frame(Addr);
 }
 
 #endif
 
 void RTDyldMemoryManager::registerEHFrames(uint8_t *Addr, uint64_t LoadAddr,
                                            size_t Size) {
+  if (Size == 0)
+    return;
   registerEHFramesInProcess(Addr, Size);
   EHFrames.push_back({Addr, Size});
 }
 
 void RTDyldMemoryManager::deregisterEHFrames() {
   for (auto &Frame : EHFrames)
     deregisterEHFramesInProcess(Frame.Addr, Frame.Size);
   EHFrames.clear();

llvm/lib/MC/MCDwarf.cpp

return LHS.Personality == RHS.Personality &&
            LHS.IsBKeyFrame == RHS.IsBKeyFrame;
   }
 };
 
 } // end namespace llvm
 
 void MCDwarfFrameEmitter::Emit(MCObjectStreamer &Streamer, MCAsmBackend *MAB,
                                bool IsEH) {
-  Streamer.generateCompactUnwindEncodings(MAB);
-
   MCContext &Context = Streamer.getContext();
   const MCObjectFileInfo *MOFI = Context.getObjectFileInfo();
   const MCAsmInfo *AsmInfo = Context.getAsmInfo();
   FrameEmitterImpl Emitter(IsEH, Streamer);
   ArrayRef<MCDwarfFrameInfo> FrameArray = Streamer.getDwarfFrameInfos();
 
   // Emit the compact unwind info if available.
   bool NeedsEHFrameSection = !MOFI->getSupportsCompactUnwindWithoutEHFrame();
   if (IsEH && MOFI->getCompactUnwindSection()) {
+    Streamer.generateCompactUnwindEncodings(MAB);
     bool SectionEmitted = false;
     for (const MCDwarfFrameInfo &Frame : FrameArray) {
       if (Frame.CompactUnwindEncoding == 0) continue;
       if (!SectionEmitted) {
         Streamer.SwitchSection(MOFI->getCompactUnwindSection());
         Streamer.emitValueToAlignment(AsmInfo->getCodePointerSize());
         SectionEmitted = true;
       }

llvm/lib/MC/MCObjectFileInfo.cpp

EHFrameSection = Ctx->getMachOSection(
       MachO::S_COALESCED | MachO::S_ATTR_NO_TOC |
           MachO::S_ATTR_STRIP_STATIC_SYMS | MachO::S_ATTR_LIVE_SUPPORT,
       SectionKind::getReadOnly());
 
   if (T.isOSDarwin() &&
       (T.getArch() == Triple::aarch64 || T.getArch() == Triple::aarch64_32))
     SupportsCompactUnwindWithoutEHFrame = true;
 
-  if (T.isWatchABI())
-    OmitDwarfIfHaveCompactUnwind = true;
+  OmitDwarfIfHaveCompactUnwind = !Ctx->getGenDwarfForAssembly();
 
   FDECFIEncoding = dwarf::DW_EH_PE_pcrel;
 
   // .comm doesn't support alignment before Leopard.
   if (T.isMacOSX() && T.isMacOSXVersionLT(10, 5))
     CommDirectiveSupportsAlignment = false;
 
   TextSection // .text

llvm/test/ExecutionEngine/MCJIT/eh-lg-pic.ll

+; FIXME
+; XFAIL: *
+
 ; REQUIRES: cxx-shared-library
 ; RUN: %lli -jit-kind=mcjit -relocation-model=pic -code-model=large %s
 ; XFAIL: cygwin, windows-msvc, windows-gnu, mips-, mipsel-, i686, i386, aarch64, arm
 declare i8* @__cxa_allocate_exception(i64)
 declare void @__cxa_throw(i8*, i8*, i8*)
 declare i32 @__gxx_personality_v0(...)
 declare void @__cxa_end_catch()
 declare i8* @__cxa_begin_catch(i8*)

llvm/test/ExecutionEngine/MCJIT/eh.ll

+; FIXME
+; XFAIL: *
+
 ; REQUIRES: cxx-shared-library
 ; RUN: %lli -jit-kind=mcjit %s
 
 ; XFAIL: arm, cygwin, windows-msvc, windows-gnu
 declare i8* @__cxa_allocate_exception(i64)
 declare void @__cxa_throw(i8*, i8*, i8*)
 declare i32 @__gxx_personality_v0(...)
 declare void @__cxa_end_catch()

llvm/test/ExecutionEngine/MCJIT/multi-module-eh-a.ll

+; FIXME
+; XFAIL: *
+
 ; REQUIRES: cxx-shared-library
 ; RUN: %lli -jit-kind=mcjit -extra-module=%p/Inputs/multi-module-eh-b.ll %s
 
 ; XFAIL: arm, cygwin, windows-msvc, windows-gnu
 declare i8* @__cxa_allocate_exception(i64)
 declare void @__cxa_throw(i8*, i8*, i8*)
 declare i32 @__gxx_personality_v0(...)
 declare void @__cxa_end_catch()

llvm/test/ExecutionEngine/MCJIT/remote/eh.ll

+; FIXME
+; XFAIL: *
+
 ; REQUIRES: cxx-shared-library
 ; RUN: %lli -jit-kind=mcjit -remote-mcjit -mcjit-remote-process=lli-child-target%exeext %s
 ; XFAIL: arm, cygwin, windows-msvc, windows-gnu
 ; UNSUPPORTED: powerpc64-unknown-linux-gnu
 ; Remove UNSUPPORTED for powerpc64-unknown-linux-gnu if problem caused by r266663 is fixed
 ; FIXME: Something hangs here.
 ; UNSUPPORTED: use_msan_with_origins
 declare i8* @__cxa_allocate_exception(i64)

llvm/test/ExecutionEngine/OrcLazy/minimal-throw-catch.ll

+; FIXME
+; XFAIL: *
+
 ; REQUIRES: system-darwin
 ; RUN: lli -jit-kind=orc-lazy %s
 ;
 ; Basic correctness testing for eh-frame processing and registration.
 
 source_filename = "minimal-throw-catch.cpp"
 target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.14.0"

llvm/test/ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s

 # RUN: rm -rf %t && mkdir -p %t
-# RUN: llvm-mc -triple=x86_64-apple-macosx10.9 -filetype=obj -o %t/test_x86-64.o %s
+# RUN: llvm-mc -g -triple=x86_64-apple-macosx10.9 -filetype=obj -o %t/test_x86-64.o %s
 # RUN: llvm-rtdyld -triple=x86_64-apple-macosx10.9 -dummy-extern ds1=0xfffffffffffffffe -dummy-extern ds2=0xffffffffffffffff -verify -check=%s %t/test_x86-64.o
 
         .section  __TEXT,__text,regular,pure_instructions
   .globl  foo
   .align  4, 0x90
 foo:
         retq
 

llvm/test/MC/ELF/cfi-version.ll

-; RUN: %llc_dwarf %s -o - -dwarf-version 2 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF2
-; RUN: %llc_dwarf %s -o - -dwarf-version 3 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF3
-; RUN: %llc_dwarf %s -o - -dwarf-version 4 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF4
-; RUN: %llc_dwarf %s -o - -dwarf-version 5 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF4
+; RUN: %llc_dwarf --force-dwarf-frame-section %s -o - -dwarf-version 2 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF2
+; RUN: %llc_dwarf --force-dwarf-frame-section %s -o - -dwarf-version 3 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF3
+; RUN: %llc_dwarf --force-dwarf-frame-section %s -o - -dwarf-version 4 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF4
+; RUN: %llc_dwarf --force-dwarf-frame-section %s -o - -dwarf-version 5 -filetype=obj | llvm-dwarfdump -v - | FileCheck %s --check-prefix=DWARF4
 
 ; PR46647
 ; XFAIL: arm64-apple
 
 ; .debug_frame is not emitted for targeting Windows x64, arm64, or AIX.
 ; REQUIRES: debug_frame
 ; REQUIRES: default_triple
 

llvm/test/MC/X86/i386-darwin-frame-register.ll

-; RUN: llc -filetype=obj %s -o - | llvm-dwarfdump -debug-frame - | FileCheck %s
+; RUN: llc --force-dwarf-frame-section -filetype=obj %s -o - | llvm-dwarfdump -debug-frame - | FileCheck %s
 
 ; IR reduced from a dummy:
 ; void foo() {}
 
 ; x86 Darwin uses different register mappings for eh_frame and debug_frame
 ; sections. Check that the right mapping is used in debug_frame.
 ; In the debug_frame mapping, register 4 is ESP, thus the below tests that
 ; the CFA is ESP+4 upon function entry.

llvm/test/tools/dsymutil/X86/frame-1.test

 # RUN: rm -rf %t
 # RUN: mkdir -p %t
-# RUN: llc -filetype=obj %p/../Inputs/frame-dw2.ll -o %t/frame-dw2.o
+# RUN: llc --force-dwarf-frame-section -filetype=obj %p/../Inputs/frame-dw2.ll -o %t/frame-dw2.o
 # RUN: dsymutil -f -oso-prepend-path=%t -y %s -o - | llvm-dwarfdump -debug-frame - | FileCheck %s
 
 # This test is meant to verify that identical CIEs will get reused
 # in the same file but also inbetween files. For this to happen, we
 # link twice the same file using this made-up debug map:
 
 ---
 triple:          'i386-apple-darwin'

llvm/test/tools/dsymutil/X86/frame-2.test

 # RUN: rm -rf %t
 # RUN: mkdir -p %t
-# RUN: llc -filetype=obj %p/../Inputs/frame-dw2.ll -o %t/frame-dw2.o
-# RUN: llc -filetype=obj %p/../Inputs/frame-dw4.ll -o %t/frame-dw4.o
+# RUN: llc --force-dwarf-frame-section -filetype=obj %p/../Inputs/frame-dw2.ll -o %t/frame-dw2.o
+# RUN: llc --force-dwarf-frame-section -filetype=obj %p/../Inputs/frame-dw4.ll -o %t/frame-dw4.o
 # RUN: dsymutil -f -oso-prepend-path=%t -y %s -o - | llvm-dwarfdump -debug-frame - | FileCheck %s
 
 # Check the handling of multiple different CIEs. To have CIEs that
 # appear to be different, use a dwarf2 version of the file along with
 # a dwarf 4 version. The CIE header version (and layout) will be different.
 ---
 triple:          'i386-apple-darwin'
 objects:

llvm/test/tools/llvm-dwarfdump/X86/debug_frame_offset.test

-RUN: llc -filetype=obj %p/../../dsymutil/Inputs/frame-dw2.ll -o - \
+RUN: llc --force-dwarf-frame-section -filetype=obj %p/../../dsymutil/Inputs/frame-dw2.ll -o - \
 RUN:   | llvm-dwarfdump -debug-frame=0x00000014 - | FileCheck %s
 CHECK: .debug_frame contents:
 CHECK-NEXT: 00000014 00000014 00000000 FDE cie=00000000 pc=00000000...0000001d
 CHECK-NEXT:   Format:       DWARF32
 CHECK-NEXT:   DW_CFA_advance_loc: 1
 CHECK-NOT: pc
 
 RUN: llvm-dwarfdump %p/../../dsymutil/Inputs/basic1.macho.x86_64.o \
 RUN:   -eh-frame=0x00000018 | FileCheck %s --check-prefix=EH
 EH: .eh_frame contents:
 EH-NEXT: 00000018 00000024 0000001c FDE cie=00000000 pc=00000000...00000024
 EH-NEXT:   Format:       DWARF32
 EH-NEXT:   DW_CFA_advance_loc: 1
 EH-NOT: pc
 EH-NOT: CIE

llvm/tools/llc/llc.cpp

if (!RunPassNames->empty()) {
       TPC.setInitialized();
       PM.add(createPrintMIRPass(*OS));
       PM.add(createFreeMachineFunctionPass());
     } else if (Target->addPassesToEmitFile(
                    PM, *OS, DwoOut ? &DwoOut->os() : nullptr,
                    codegen::getFileType(), NoVerify, MMIWP)) {
       reportError("target does not support generation of this file type");
     }
-
+    auto &Ctx = MMIWP->getMMI().getContext();
+    Ctx.setGenDwarfForAssembly(Target->Options.ForceDwarfFrameSection);
     const_cast<TargetLoweringObjectFile *>(LLVMTM.getObjFileLowering())
-        ->Initialize(MMIWP->getMMI().getContext(), *Target);
+        ->Initialize(Ctx, *Target);
     if (MIR) {
       assert(MMIWP && "Forgot to create MMIWP?");
       if (MIR->parseMachineFunctions(*M, MMIWP->getMMI()))
         return 1;
     }
 
     // Before executing passes, print the final values of the LLVM options.
     cl::PrintOptionValues();

llvm/tools/llvm-mc/llvm-mc.cpp

int main(int argc, char **argv) {
   std::unique_ptr<MCSubtargetInfo> STI(
       TheTarget->createMCSubtargetInfo(TripleName, MCPU, FeaturesStr));
   assert(STI && "Unable to create subtarget info!");
 
   // FIXME: This is not pretty. MCContext has a ptr to MCObjectFileInfo and
   // MCObjectFileInfo needs a MCContext reference in order to initialize itself.
   MCContext Ctx(TheTriple, MAI.get(), MRI.get(), STI.get(), &SrcMgr,
                 &MCOptions);
+  Ctx.setGenDwarfForAssembly(GenDwarfForAssembly);
   std::unique_ptr<MCObjectFileInfo> MOFI(
       TheTarget->createMCObjectFileInfo(Ctx, PIC, LargeCodeModel));
   Ctx.setObjectFileInfo(MOFI.get());
 
   if (SaveTempLabels)
     Ctx.setAllowTemporaryLabels(false);
 
-  Ctx.setGenDwarfForAssembly(GenDwarfForAssembly);
   // Default to 4 for dwarf version.
   unsigned DwarfVersion = MCOptions.DwarfVersion ? MCOptions.DwarfVersion : 4;
   if (DwarfVersion < 2 || DwarfVersion > 5) {
     errs() << ProgName << ": Dwarf version " << DwarfVersion
            << " is not supported." << '\n';
     return 1;
   }
   Ctx.setDwarfVersion(DwarfVersion);