[Driver] Add DWARF64 flag: -gdwarf64

[ayermolo]

Summary

@ikudrin enabled support for dwarf64 in D87011. Adding a clang flag so it can be used through that compilation pass.

[ikudrin]

1. The patch needs tests to check the added functionality.
2. DWARF64 can be generated only for a limited number of targets. There should be diagnostics for invalid switch combinations to prevent misuse. @MaskRay mentioned that in the patch for llc, D87011#2254749, but that makes a lot more sense for user-level tools.

[ayermolo]

In D90507#2378015, @ikudrin wrote:

1. The patch needs tests to check the added functionality.
2. DWARF64 can be generated only for a limited number of targets. There should be diagnostics for invalid switch combinations to prevent misuse. @MaskRay mentioned that in the patch for llc, D87011#2254749, but that makes a lot more sense for user-level tools.

Thanks, added some checks and clang tests.

[ayermolo]

The failure seems unrelated to my changes. Trying locally it fails with latest upstream even without my changes.

[ayermolo]

@jansvoboda11 Can you take a look? The failing test is unrelated it seems. Fails locally even without my change.

[jansvoboda11]

Hi @ayermolo, do you think this might be triggered by D82756? (my only upstream patch ATM)

clang/test/Driver/debug-options.c

376–392

Probably extra character.

[wenlei]

This change covers non-LTO cases. For LTO, I think we would need to pass it from driver to LTO. Something like this: tools::addLTOOptions -> lld -> lto::Config (Config->TargetOptions->MCTargetOptions) ->LTO Backend.

[ayermolo]

In D90507#2393434, @jansvoboda11 wrote:

Hi @ayermolo, do you think this might be triggered by D82756? (my only upstream patch ATM)

Oh, no. Sorry I wasn't clear. I was just looking for people to review this patch, and saw you recently reviewed another patch.

[ayermolo]

In D90507#2394109, @wenlei wrote:

This change covers non-LTO cases. For LTO, I think we would need to pass it from driver to LTO. Something like this: tools::addLTOOptions -> lld -> lto::Config (Config->TargetOptions->MCTargetOptions) ->LTO Backend.

Good point. Maybe part of a different diff, since lld needs to be modified also.

[dblaikie]

clang/include/clang/Basic/CodeGenOptions.def

35

Is there any precedent to draw from for this flag name? (Does GCC support DWARF64? Does it support it under this flag name or some other? (similarly with other gcc-like compilers (Intel's? Whoever else... )))

[ikudrin]

It looks like lld/test/COFF/lto-new-pass-manager.ll.obj was added to the patch by accident and should be removed.

clang/include/clang/Basic/CodeGenOptions.def

35

It looks like we are pioneering in that area. To me, the proposed name looks consonant with other debug-related switches.

clang/lib/Driver/ToolChains/Clang.cpp

4030

We also should check that the output format is ELF.

[ayermolo]

In D90507#2398654, @ikudrin wrote:

It looks like lld/test/COFF/lto-new-pass-manager.ll.obj was added to the patch by accident and should be removed.

It's weird. The file gets automatically added whenever I commit the files I have modified locally.

[ayermolo]

clang/include/clang/Basic/CodeGenOptions.def

35

I didn't see any dwarf64 flags in gcc:
https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

I tried to follow clang convention for other dwarf flags.

[MaskRay]

clang/lib/Driver/ToolChains/Clang.cpp

4020

if (const Arg *A = Args.getLastArg(options::OPT_gdwarf64))

4022

The variable is only used once. Inline it

[MaskRay]

Adding DWARF64 clang flag

It is important to mention the exact option name: Add -gdwarf-64 to enable 64-bit DWARF format

[ayermolo]

clang/lib/Driver/ToolChains/Clang.cpp

4022

Both A, and RawTriple are used more than once.

[dblaikie]

clang/include/clang/Driver/Options.td

2577–2578

Does this actually enable debug info emission (the -gdwarf-N versions do cause debug info to be emitted, and set the dwarf version - but, say -ggnu-pubnames does not cause debug info to be emitted if it isn't otherwise requested). Experience has shown it's probably better to have flags like this not enable debug info emission - so they can be used orthogonally (eg: if a project is large, it can add -gdwarf64 to its flags permanently, even though maybe only some build modes, etc, enable debug info (with -g))

If this doesn't enable debug info emission, the phrasing of the help text might be worth changing somewhat (I wonder how we document -ggnu-pubnames, for instance/comparison/inspiration)

clang/lib/Driver/ToolChains/Clang.cpp

4024–4025

perhaps we could phrase this more generally (so it's true even when DWARFv6 comes along - and doesn't get unwieldy listing all the DWARF versions).

"DWARFv3 or later" ?

4030

Is DWARF64 not supported on MachO, for instance? (I'd have DWARF64 would be pretty usable on any platform that supported DWARF in general - certainly some system tools that are DWARF aware (including actual debuggers) might not be up to the task of using it - but if we can correctly generate it in the object files, it seems OK to accept the request (useful for folks testing out/implementing DWARF64 consumers on those platforms))

clang/test/Driver/debug-options.c

389

Typo in "architecture"

[ayermolo]

clang/include/clang/Driver/Options.td

2577–2578

This enables DWARF64 if emission is enabled.

From DebugInfo it seems like it's only Elf Format:

bool Dwarf64 = Asm->TM.Options.MCOptions.Dwarf64 &&

DwarfVersion >= 3 &&   // DWARF64 was introduced in DWARFv3.
TT.isArch64Bit() &&    // DWARF64 requires 64-bit relocations.
TT.isOSBinFormatELF(); // Support only ELF for now.

[ayermolo]

clang/include/clang/Driver/Options.td

2577–2578

This enables DWARF64 if emission is enabled.

clang/lib/Driver/ToolChains/Clang.cpp

4030

From DebugInfo it seems like it's only Elf Format:

bool Dwarf64 = Asm->TM.Options.MCOptions.Dwarf64 &&
                 DwarfVersion >= 3 &&   // DWARF64 was introduced in DWARFv3.
                 TT.isArch64Bit() &&    // DWARF64 requires 64-bit relocations.
                TT.isOSBinFormatELF(); // Support only ELF for now.

[dblaikie]

clang/include/clang/Driver/Options.td

2577–2578

This enables DWARF64 if emission is enabled.

Then perhaps the Help Text phrasing should distinguish this behavior from the behavior of -gdwarf-N which not only sets the version, but enables emission. (perhaps the phrasing of flags that don't enable emission, like "-ggnu-pubnames" could provide inspiration for phrasing the help text for this new flag)

From DebugInfo it seems like it's only Elf Format:

I'm curious as to why it's ELF only, though - could you explain what the motivation is there?

(random aside: I still worry about this precedent for -g* flags that sometimes enable debug info and set a feature, and sometimes they only set the feature and don't enable debug info - it's a bit of a confusing mess and I personally rather the -fdebug* flags set a feature but don't enable emission and -g* flags enable emission, but there's a lack of clear agreement and there's examples on both sides, so not sure there's much to be done about that here)

[ikudrin]

clang/include/clang/Driver/Options.td

2577–2578

From DebugInfo it seems like it's only Elf Format:

I'm curious as to why it's ELF only, though - could you explain what the motivation is there?

Our customers need DWARF64 for ELF and I do not have much experience with other platforms, so I cannot provide adequate support there. Some platform-specific tools, like dsymutil, have to be fixed to work with DWARF64, but I am personally a bit reluctant to do that because I cannot check the result in practice. If there will be developers who are willing to support DWARF64 on these platforms, they will be able to unlock it and use all the experience we collect with ELF, but for now, I prefer to focus on one particular platform with practical applications.

[dblaikie]

clang/lib/Driver/ToolChains/Clang.cpp

4025

clang/test/Driver/debug-options.c

388

[dblaikie]

clang/include/clang/Basic/CodeGenOptions.def

35

Huh - tried making really big binaries or anything (or checking the GCC source) to see if it does it implicitly under some conditions?
Hmm - looks like this maybe came up at the Linux Plumbers Conference & the suggested flag was -fdwarf64/32: https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf (this avoids the "does g imply debug info" and avoids the subtle distinction between "-gdwarf64 and -gdwarf-N" the presence of the '-' changing the meaning of the number quite significantly). Though hardly authoritative
https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt - seems some other options were (are?) under consideration too. Might be worth touching base with the folks involved in those discussions to see where they're at with regard to naming/support?

(they also touch on the "all units must agree" issue - so not sure if the same folks involved in those discussions have also been included in the discussions around debug info 32/64 sorting as another approach that may avoid the "all units must agree" constraint (I assume that's the reason they had that constraint))

[ayermolo]

clang/include/clang/Basic/CodeGenOptions.def

35

In the DWARFV5-64 pdf it says 64 bit support has no patches and is after DWARF5. Although it's not clear if they are talking about DWARF64 support for V5 or in general.

I have not hacked our build system to use gcc for builds that can overflow debug_info. I scanned through gcc code and was only able to find references to dwarf 64 in go library, and in dwarf2out.c. In latter it relies on DWARF_OFFSET_SIZE macro.

I don't quite understand the "all [CU] units must agree" part either. From DWARF perspective we are free to match on CU level DWARF32/64, and consumer are free not to do anything beyond that. So if overflow occurs, will so be it. What we are trying to do in linker with sorting is being "nice" to the users, and kind of going beyond what spec requires.

Sounds like no conclusion was reached on their side, but only one of them -gdwarf64 follows naming convention of other debug flags.

• -fdwarf64/-fdwarf32
  • or -gdwarf32 or -gdwarf64
  • or -gdbdwarf=32/64

[dblaikie]

clang/include/clang/Basic/CodeGenOptions.def

35

only one of them -gdwarf64 follows naming convention of other debug flags.

There are many debug flags that don't use the '-g' prefix. (-fdebug-types-section comes to mind, but I think - this was discussed in depth earlier this year with regards to the -gsplit-dwarf flag, for instance: https://www.mail-archive.com/[e-mail]/msg92495.html - though at least the DWARF64 flag doesn't have the legacy that -gsplit-dwarf has that complicates things further there)

[ayermolo]

clang/include/clang/Basic/CodeGenOptions.def

35

Ah, thanks for the context. My takeaway it's a mess. :)
Personally I find it more confusing that there are debug options that start with -f and -g, rather then that some -g enable debug output. When I look at documentation I just want to have see all the related options grouped in one area/one prefix, but that's just how my brain works.
That being said I don't have particular strong opinion about naming convention of this flag. Judging from that conversation, maybe there is some preference for -f, but mainly it was a big push against changing an option after it was introduced and proliferated.

[dblaikie]

clang/include/clang/Basic/CodeGenOptions.def

35

Yep, bit of a mess - hence the concern about making it messier/trying to drive in that general direction.

Could you reach out to the gcc mailing list, link the thread I linked, CC myself (& anyone else from this review who seems interested) and any of the folks you might be able to identify from the Plumbers conference or other context that seems to have an interest in this & ask what they think the flag should be?

I ask because so far as I can tell from prior experience, GCC is less likely to adopt Clang's convention out of compatibility, so it's more on us to try to pick something with some buy-in from their side of things lest we end up with divergent flags or semantics.

[ayermolo]

clang/include/clang/Basic/CodeGenOptions.def

35

Made a post: https://gcc.gnu.org/pipermail/gcc/2020-November/234290.html
CCed people in this review + Mark Wielaard.

[dblaikie]

clang/include/clang/Basic/CodeGenOptions.def

35

Seems like that thread eventually settled into someone submitting a patch to GCC with -gdwarf32/64 and them not implying -g by default.

So that's consistent with this patch you're proposing here, right?

Could you check the wording that the GCC patch uses for description/details/user manual and compare it with the wording you're proposing here?

[ayermolo]

---

From: David Blaikie via Phabricator <[e-mail]>
Sent: Monday, December 7, 2020 11:08 AM
To: Alexander Yermolovich <[e-mail]>; [e-mail] <[e-mail]>
Cc: Hongtao Yu <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Wenlei He <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [PATCH] D90507: [Driver] Add DWARF64 flag: -gdwarf64

dblaikie added inline comments.
Herald added a subscriber: hoy.

Comment at: clang/include/clang/Basic/CodeGenOptions.def:35
CODEGENOPT(AsmVerbose , 1, 0) /< -dA, -fverbose-asm.
+CODEGENOPT(Dwarf64 , 1, 0) /< -gdwarf64.

CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.

ayermolo wrote:

dblaikie wrote:

ayermolo wrote:

dblaikie wrote:

ayermolo wrote:

dblaikie wrote:

ayermolo wrote:

ikudrin wrote:

dblaikie wrote:

Is there any precedent to draw from for this flag name? (Does GCC support DWARF64? Does it support it under this flag name or some other? (similarly with other gcc-like compilers (Intel's? Whoever else... )))

It looks like we are pioneering in that area. To me, the proposed name looks consonant with other debug-related switches.

I didn't see any dwarf64 flags in gcc:
https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

I tried to follow clang convention for other dwarf flags.

Huh - tried making really big binaries or anything (or checking the GCC source) to see if it does it implicitly under some conditions?
Hmm - looks like this maybe came up at the Linux Plumbers Conference & the suggested flag was -fdwarf64/32: https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf (this avoids the "does g imply debug info" and avoids the subtle distinction between "-gdwarf64 and -gdwarf-N" the presence of the '-' changing the meaning of the number quite significantly). Though hardly authoritative
https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt - seems some other options were (are?) under consideration too. Might be worth touching base with the folks involved in those discussions to see where they're at with regard to naming/support?

(they also touch on the "all units must agree" issue - so not sure if the same folks involved in those discussions have also been included in the discussions around debug info 32/64 sorting as another approach that may avoid the "all units must agree" constraint (I assume that's the reason they had that constraint))

In the DWARFV5-64 pdf it says 64 bit support has no patches and is after DWARF5. Although it's not clear if they are talking about DWARF64 support for V5 or in general.

I have not hacked our build system to use gcc for builds that can overflow debug_info. I scanned through gcc code and was only able to find references to dwarf 64 in go library, and in dwarf2out.c. In latter it relies on DWARF_OFFSET_SIZE macro.

I don't quite understand the "all [CU] units must agree" part either. From DWARF perspective we are free to match on CU level DWARF32/64, and consumer are free not to do anything beyond that. So if overflow occurs, will so be it. What we are trying to do in linker with sorting is being "nice" to the users, and kind of going beyond what spec requires.

Sounds like no conclusion was reached on their side, but only one of them -gdwarf64 follows naming convention of other debug flags.

• -fdwarf64/-fdwarf32
  • or -gdwarf32 or -gdwarf64
  • or -gdbdwarf=32/64

only one of them -gdwarf64 follows naming convention of other debug flags.

There are many debug flags that don't use the '-g' prefix. (-fdebug-types-section comes to mind, but I think - this was discussed in depth earlier this year with regards to the -gsplit-dwarf flag, for instance: https://www.mail-archive.com/[e-mail]/msg92495.html - though at least the DWARF64 flag doesn't have the legacy that -gsplit-dwarf has that complicates things further there)

Ah, thanks for the context. My takeaway it's a mess. :)
Personally I find it more confusing that there are debug options that start with -f and -g, rather then that some -g enable debug output. When I look at documentation I just want to have see all the related options grouped in one area/one prefix, but that's just how my brain works.
That being said I don't have particular strong opinion about naming convention of this flag. Judging from that conversation, maybe there is some preference for -f, but mainly it was a big push against changing an option after it was introduced and proliferated.

Yep, bit of a mess - hence the concern about making it messier/trying to drive in that general direction.

Could you reach out to the gcc mailing list, link the thread I linked, CC myself (& anyone else from this review who seems interested) and any of the folks you might be able to identify from the Plumbers conference or other context that seems to have an interest in this & ask what they think the flag should be?

I ask because so far as I can tell from prior experience, GCC is less likely to adopt Clang's convention out of compatibility, so it's more on us to try to pick something with some buy-in from their side of things lest we end up with divergent flags or semantics.

Made a post: https://gcc.gnu.org/pipermail/gcc/2020-November/234290.html
CCed people in this review + Mark Wielaard.

Seems like that thread eventually settled into someone submitting a patch to GCC with -gdwarf32/64 and them not implying -g by default.

So that's consistent with this patch you're proposing here, right?

Could you check the wording that the GCC patch uses for description/details/user manual and compare it with the wording you're proposing here?
[Alex]
From commit message:
"dwarf: Add -gdwarf{32,64} options

The following patch makes the choice between 32-bit and 64-bit DWARF formats
selectable by command line switch, rather than being hardcoded through
DWARF_OFFSET_SIZE macro.

The options themselves don't turn on debug info themselves, so one needs
to use -g -gdwarf64 or similar."

Sounds like it is settled then. I'll update my llvm diff accordingly, mainly adding -gdwarf32 flag.

Repository:

rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION

https://reviews.llvm.org/D90507/new/

https://reviews.llvm.org/D90507

[MaskRay]

clang/lib/Driver/ToolChains/Clang.cpp

4033

Use render (see other render in the file)

clang/test/Driver/debug-options.c

378

Append -c to test just the compile action.

x86_64-linux-gnu -> x86_64 to make it clear this is a generic ELF behavior (e.g. FreeBSD works).

382

Don't repeat -target x86_64-linux-gnu

[MaskRay]

clang/test/Driver/debug-options.c

389

The diagnostic elf output format is untested. Please add an x86_64-apple-darwin test.

[MaskRay]

clang/lib/Driver/ToolChains/Clang.cpp

4031

"elf output format" -> "ELF platforms"

ELF is usually capitalized. Here I think "platforms" is probably more suitable than "output format" (which I'd prefer "binary format")

[MaskRay]

clang/lib/Driver/ToolChains/Clang.cpp

4033

Delete unneeded braces

http://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements

clang/test/Driver/debug-options.c

378

I'd prefer x86_64 (generic ELF) to indicate that this is a generic ELF feature, not specific to Linux (i.e. FreeBSD works)

[ikudrin]

clang/lib/Driver/ToolChains/Clang.cpp

4020

Maybe make this more descriptive?

clang/test/Driver/debug-options.c

391

[MaskRay]

clang/test/Driver/debug-options.c

379

// VALIDT: x86_64

lit does not replace VALIDT with x86_64. Do you just want to test -target x86_64?

[ayermolo]

clang/test/Driver/debug-options.c

379

A, you are right. Should have checked lit with -a.
I was trying to address:
"x86_64-linux-gnu -> x86_64 to make it clear this is a generic ELF behavior (e.g. FreeBSD works)."
"Don't repeat -target x86_64-linux-gnu"

I guess this only works for --check-prefix.

[ayermolo]

@dblaikie @MaskRay Anything else do I need to change, all good?

[MaskRay]

LGTM.

[ayermolo]

rebased on latest.

clang/include/clang/Basic/CodeGenOptions.def

 CODEGENOPT(Name, Bits, Default)
 #endif
 
 CODEGENOPT(DisableIntegratedAS, 1, 0) ///< -no-integrated-as
 ENUM_CODEGENOPT(CompressDebugSections, llvm::DebugCompressionType, 2,
                 llvm::DebugCompressionType::None)
 CODEGENOPT(RelaxELFRelocations, 1, 0) ///< -Wa,--mrelax-relocations
 CODEGENOPT(AsmVerbose        , 1, 0) ///< -dA, -fverbose-asm.
+CODEGENOPT(Dwarf64           , 1, 0) ///< -gdwarf64.
+CODEGENOPT(Dwarf32           , 1, 1) ///< -gdwarf32.
 CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
 CODEGENOPT(AssumeSaneOperatorNew , 1, 1) ///< implicit __attribute__((malloc)) operator new
 CODEGENOPT(Autolink          , 1, 1) ///< -fno-autolink
 CODEGENOPT(ObjCAutoRefCountExceptions , 1, 0) ///< Whether ARC should be EH-safe.
 CODEGENOPT(Backchain         , 1, 0) ///< -mbackchain
 CODEGENOPT(IgnoreXCOFFVisibility         , 1, 0) ///< -mignore-xcoff-visibility
 CODEGENOPT(ControlFlowGuardNoChecks  , 1, 0) ///< -cfguard-no-checks
 CODEGENOPT(ControlFlowGuard  , 1, 0) ///< -cfguard

clang/include/clang/Driver/Options.td

 def gdwarf_2 : Flag<["-"], "gdwarf-2">, Group<g_Group>,
   HelpText<"Generate source-level debug information with dwarf version 2">;
 def gdwarf_3 : Flag<["-"], "gdwarf-3">, Group<g_Group>,
   HelpText<"Generate source-level debug information with dwarf version 3">;
 def gdwarf_4 : Flag<["-"], "gdwarf-4">, Group<g_Group>,
   HelpText<"Generate source-level debug information with dwarf version 4">;
 def gdwarf_5 : Flag<["-"], "gdwarf-5">, Group<g_Group>,
   HelpText<"Generate source-level debug information with dwarf version 5">;
+def gdwarf64 : Flag<["-"], "gdwarf64">, Group<g_Group>, Flags<[CC1Option]>,
+  HelpText<"Enables DWARF64 format for ELF binaries, if debug information emission is enabled.">;
+def gdwarf32 : Flag<["-"], "gdwarf32">, Group<g_Group>, Flags<[CC1Option]>,
+  HelpText<"Enables DWARF32 format for ELF binaries, if debug information emission is enabled.">;
 
 def gcodeview : Flag<["-"], "gcodeview">,
   HelpText<"Generate CodeView debug information">,
   Flags<[CC1Option, CC1AsOption, CoreOption]>,
   MarshallingInfoFlag<"CodeGenOpts.EmitCodeView">;
 defm codeview_ghash : BoolOption<"codeview-ghash",
   "CodeGenOpts.CodeViewGHash", DefaultsToFalse,
   ChangedBy<PosFlag, [CC1Option], "Emit type record hashes in a .debug$H section">,

clang/lib/CodeGen/BackendUtil.cpp

static bool initTargetOptions(DiagnosticsEngine &Diags,
   Options.MCOptions.MCSaveTempLabels = CodeGenOpts.SaveTempLabels;
   Options.MCOptions.MCUseDwarfDirectory = !CodeGenOpts.NoDwarfDirectoryAsm;
   Options.MCOptions.MCNoExecStack = CodeGenOpts.NoExecStack;
   Options.MCOptions.MCIncrementalLinkerCompatible =
       CodeGenOpts.IncrementalLinkerCompatible;
   Options.MCOptions.MCFatalWarnings = CodeGenOpts.FatalWarnings;
   Options.MCOptions.MCNoWarn = CodeGenOpts.NoWarn;
   Options.MCOptions.AsmVerbose = CodeGenOpts.AsmVerbose;
+  Options.MCOptions.Dwarf64 = CodeGenOpts.Dwarf64;
   Options.MCOptions.PreserveAsmComments = CodeGenOpts.PreserveAsmComments;
   Options.MCOptions.ABIName = TargetOpts.ABI;
   for (const auto &Entry : HSOpts.UserEntries)
     if (!Entry.IsFramework &&
         (Entry.Group == frontend::IncludeDirGroup::Quoted ||
          Entry.Group == frontend::IncludeDirGroup::Angled ||
          Entry.Group == frontend::IncludeDirGroup::System))
       Options.MCOptions.IASSearchPaths.push_back(

clang/lib/Driver/ToolChains/Clang.cpp

static void RenderDebugOptions(const ToolChain &TC, const Driver &D,
   if (DebuggerTuning == llvm::DebuggerKind::SCE)
     CmdArgs.push_back("-debug-forward-template-params");
 
   // Do we need to explicitly import anonymous namespaces into the parent
   // scope?
   if (DebuggerTuning == llvm::DebuggerKind::SCE)
     CmdArgs.push_back("-dwarf-explicit-import");
 
+  auto *DwarfFormatArg =
+      Args.getLastArg(options::OPT_gdwarf64, options::OPT_gdwarf32);
+  if (DwarfFormatArg &&
+      DwarfFormatArg->getOption().matches(options::OPT_gdwarf64)) {
+    const llvm::Triple &RawTriple = TC.getTriple();
+    if (EffectiveDWARFVersion < 3)
+      D.Diag(diag::err_drv_argument_only_allowed_with)
+          << DwarfFormatArg->getAsString(Args) << "DWARFv3 or greater";
+    else if (!RawTriple.isArch64Bit())
+      D.Diag(diag::err_drv_argument_only_allowed_with)
+          << DwarfFormatArg->getAsString(Args) << "64 bit architecture";
+    else if (!RawTriple.isOSBinFormatELF())
+      D.Diag(diag::err_drv_argument_only_allowed_with)
+          << DwarfFormatArg->getAsString(Args) << "ELF platforms";
+  }
+
+  if (DwarfFormatArg)
+    DwarfFormatArg->render(Args, CmdArgs);
+
   RenderDebugInfoCompressionArgs(Args, CmdArgs, D, TC);
 }
 
 void Clang::ConstructJob(Compilation &C, const JobAction &JA,
                          const InputInfo &Output, const InputInfoList &Inputs,
                          const ArgList &Args, const char *LinkingOutput) const {
   const auto &TC = getToolChain();
   const llvm::Triple &RawTriple = TC.getTriple();

clang/lib/Frontend/CompilerInvocation.cpp

Opts.DebugNameTable = static_cast<unsigned>(
           : Args.hasArg(OPT_gpubnames)
                 ? llvm::DICompileUnit::DebugNameTableKind::Default
                 : llvm::DICompileUnit::DebugNameTableKind::None);
 
   if (!Opts.ProfileInstrumentUsePath.empty())
     setPGOUseInstrumentor(Opts, Opts.ProfileInstrumentUsePath);
 
   Opts.CodeModel = TargetOpts.CodeModel;
+  Opts.Dwarf64 = Args.hasArg(OPT_gdwarf64);
 
   if (const Arg *A = Args.getLastArg(OPT_ftime_report, OPT_ftime_report_EQ)) {
     Opts.TimePasses = true;
 
     // -ftime-report= is only for new pass manager.
     if (A->getOption().getID() == OPT_ftime_report_EQ) {
       if (Opts.LegacyPassManager)
         Diags.Report(diag::err_drv_argument_only_allowed_with)

clang/test/Driver/debug-options.c

 // RUN:        | FileCheck -check-prefix=DEBUG_UNUSED_TYPES %s
 // DEBUG_UNUSED_TYPES: "-debug-info-kind=unused-types"
 // DEBUG_UNUSED_TYPES-NOT: "-debug-info-kind=limited"
 // RUN: %clang -### -g -feliminate-unused-debug-types -c %s 2>&1 \
 // RUN:        | FileCheck -check-prefix=NO_DEBUG_UNUSED_TYPES %s
 // RUN: %clang -### -fno-eliminate-unused-debug-types -g1 -c %s 2>&1 \
 // RUN:        | FileCheck -check-prefix=NO_DEBUG_UNUSED_TYPES %s
 // NO_DEBUG_UNUSED_TYPES: "-debug-info-kind={{limited|line-tables-only|standalone}}"
 // NO_DEBUG_UNUSED_TYPES-NOT: "-debug-info-kind=unused-types"
+//
+// RUN: %clang -### -c -gdwarf-5 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-3 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-2 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_VER %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64 -target x86_64 %s 2>&1 \
+// RUN:       | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target i386-linux-gnu %s 2>&1 \
+// RUN:       | FileCheck -check-prefix=GDWARF64_32ARCH %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64-apple-darwin %s 2>&1 \
+// RUN:       | FileCheck -check-prefix=GDWARF64_ELF %s
+//
+// GDWARF64_ON:  "-gdwarf64"
+// GDWARF64_VER:  error: invalid argument '-gdwarf64' only allowed with 'DWARFv3 or greater'
+// GDWARF64_32ARCH: error: invalid argument '-gdwarf64' only allowed with '64 bit architecture'
+// GDWARF64_ELF: error: invalid argument '-gdwarf64' only allowed with 'ELF platforms'