[DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled

[akhuang]

Summary

Constructor homing reduces the amount of class type info that is emitted
by emitting conmplete type info for a class only when a constructor for
that class is emitted.

This will mainly reduce the amount of duplicate debug info in object
files. In Chrome enabling ctor homing decreased total build directory sizes
by about 30%.

It's also expected that some class types (such as unused classes)
will no longer be emitted in the debug info. This is fine, since we wouldn't
expect to need these types when debugging.

In some cases (e.g. libc++, https://reviews.llvm.org/D98750), classes
are used without calling the constructor. Since this is technically
undefined behavior, enabling constructor homing should be fine.
However Clang now has an attribute
__attribute__((standalone_debug)) that can be used on classes to
ignore ctor homing.

Bug: https://bugs.llvm.org/show_bug.cgi?id=46537

[dblaikie]

Please wait for sign-off from @aprantl (or another appropriate Apple representative) & @probinson (or another appropriate Sony representative) as well - at least to check everyone's ready for this. (Apple I think still uses -fstandalone-debug, so won't be immediately relevant, but good to know it's coming in case some of their users are using -fno-standalone-debug or they have plans in motion, etc)

[JDevlieghere]

Adrian said "Let's do it!" on the mailing list so LGTM for Darwin.

[probinson]

+ @jmorse who is better placed than I am to say whether this is what Sony would prefer.

[jmorse]

This is going to be excellent for linux targets and similar,

In D106084#2882970, @probinson wrote:

+ @jmorse who is better placed than I am to say whether this is what Sony would prefer.

Slightly trickier -- our debugger won't resolve symbols across module boundaries (similar to the Windows debugger), which will make it hard to debug when debug/no-debug code is mixed. Would it be possible to default to -debug-info-kind=limited if DebuggerTuning == llvm::DebuggerKind::SCE? This leads to the fewest surprises in a default configuration targeting us.

[dblaikie]

In D106084#2886659, @jmorse wrote:

This is going to be excellent for linux targets and similar,

In D106084#2882970, @probinson wrote:

+ @jmorse who is better placed than I am to say whether this is what Sony would prefer.

Slightly trickier -- our debugger won't resolve symbols across module boundaries (similar to the Windows debugger), which will make it hard to debug when debug/no-debug code is mixed. Would it be possible to default to -debug-info-kind=limited if DebuggerTuning == llvm::DebuggerKind::SCE? This leads to the fewest surprises in a default configuration targeting us.

It'd be preferable not to split these two cases (current "limited" versus "ctor" homing) - because they rely on the same assumption, that the whole program is built with debug info (hence the renaming of "limited" a long time ago to "standalone-debug" to create a policy/philosophy around what goes in each category).

Wouldn't the current "limited" behavior have problems for this shared libraries situation too? Sounds like in that case -fstandalone-debug should be used.

(if it's a sliding scale and the problems caused by the current -fno-standalone-debug/-flimit-debug-info are not severe enough, but ctor-homing would be too severe... I'd probably be inclined to pushback on that being a distinction we should draw in-tree & that might be suitable to be kept downstream)

[probinson]

(hence the renaming of "limited" a long time ago to "standalone-debug" to create a policy/philosophy around what goes in each category).

Sorry, what? I thought -fstandalone-debug meant FullDebugInfo, and AFAICT that's still how the driver handles it?

[probinson]

Wouldn't the current "limited" behavior have problems for this shared libraries situation too? Sounds like in that case -fstandalone-debug should be used.

@jmorse am I remembering correctly, that we require dllimport-style annotations, so "limited" actually includes these types even if they aren't constructed locally? I am vague on the details here. But if ctor homing and limited both will consider a dllimport-ed type as requiring a full description, that's not a reason to pick one over the other.

[jmorse]

In D106084#2887702, @dblaikie wrote:

It'd be preferable not to split these two cases (current "limited" versus "ctor" homing) - because they rely on the same assumption, that the whole program is built with debug info (hence the renaming of "limited" a long time ago to "standalone-debug" to create a policy/philosophy around what goes in each category).

Wouldn't the current "limited" behavior have problems for this shared libraries situation too? Sounds like in that case -fstandalone-debug should be used.

I had a dig into what "limited" currently does -- and I think Windows most closely matches our setup. Many portions don't have the source available, the debugger behaves similarly, and the default debug-info mode there is "Limited". I think what saves our bacon is the import/export clause [0, 1], if a class is used between libraries then neither Limited or Constructor debug-info will suppress its class definition.

With that in mind, I suppose we'll be alright with constructor homing on by default. The interfaces between libraries will still have type information emitted in Constructor mode, and it's not excessive for those who want to dig deeper to run with standalone-debug.

[0] https://github.com/llvm/llvm-project/blob/4a30a5c8d9f0fa8a4b6ebd7c82d5335ae7a77521/clang/lib/CodeGen/CGDebugInfo.cpp#L2391
[1] https://github.com/llvm/llvm-project/blob/4a30a5c8d9f0fa8a4b6ebd7c82d5335ae7a77521/clang/lib/CodeGen/CGDebugInfo.cpp#L2346

[jmorse]

In D106084#2890541, @probinson wrote:

@jmorse am I remembering correctly, that we require dllimport-style annotations, so "limited" actually includes these types even if they aren't constructed locally? I am vague on the details here. But if ctor homing and limited both will consider a dllimport-ed type as requiring a full description, that's not a reason to pick one over the other.

For anything shared between modules, indeed it needs the annotations (we try to follow Windows here). I believe there can still be un-exported types from the other modules headers that qualify for inclusion under "Limited" mode but won't for "Constructor", and that's the benefit of Constructor mode / price if the other module isn't built with debug-info.

[dblaikie]

In D106084#2890469, @probinson wrote:

(hence the renaming of "limited" a long time ago to "standalone-debug" to create a policy/philosophy around what goes in each category).

Sorry, what? I thought -fstandalone-debug meant FullDebugInfo, and AFAICT that's still how the driver handles it?

Sorry, misspoke. -flimit-debug-info is -fno-standalone-debug. I meant the terminology changed, not the semantics - the terminology of "standalone" V "non-standalone" is the one that gives, in my opinion, the correct framing for when you would use one flag or the other. The core assumption of -fno-standalone-debug is that you've compiled the whole program with debug info enabled, so assumptions can be made about type debug info being carried by some other object file. If parts of the program (for instance, only one shared library has debug info and it interacts with others that don't) are built without debug info, then -fstandalone-debug is the right option to use.

In D106084#2890823, @jmorse wrote:

In D106084#2890541, @probinson wrote:

@jmorse am I remembering correctly, that we require dllimport-style annotations, so "limited" actually includes these types even if they aren't constructed locally? I am vague on the details here. But if ctor homing and limited both will consider a dllimport-ed type as requiring a full description, that's not a reason to pick one over the other.

For anything shared between modules, indeed it needs the annotations (we try to follow Windows here). I believe there can still be un-exported types from the other modules headers that qualify for inclusion under "Limited" mode but won't for "Constructor", and that's the benefit of Constructor mode / price if the other module isn't built with debug-info.

I think what I'm missing here: If -fno-standalone-debug is already in use/the default and is causing missing types because parts of the program are bulit without debug info, then I'm not sure what the rationale is for slicing -fstandalone-debug into a "has ctor homing" and a "doesn't have ctor homing" strategy. The same general design philosophy applies - that in both cases (about 4 cases in total now: types that aren't required to be complete, explicitly instantiated templates, vtables, and now ctor homing) the whole program must be compiled with debug info enabled for these DWARF size optimizations to be sound.

Is there some set of cases where the current set of homing strategies is sound, but ctor homing is not sound?

[akhuang]

Add an opt out flag: fno-use-ctor-homing

[akhuang]

Realized it's probably a good idea to add an opt out flag (counterpart to fuse-ctor-homing). Also, maybe in a separate patch, maybe should make these clang flags instead of cc1 flags-

[probinson]

clang/lib/Frontend/CompilerInvocation.cpp

1636 ↗

(On Diff #360621)

No... you want to check both options in one call, otherwise -fno-use-ctor-homing -fuse-ctor-homing will prefer the no version instead of last-one-wins.

I suggest fiddling the options should be done separately.
Also if you want to make it a clang option, the option name should have debug in it; pretty sure all the -f options related to debug info do that, and in any case it's a good idea.

[akhuang]

clang/lib/Frontend/CompilerInvocation.cpp

1636 ↗

(On Diff #360621)

ah, right.

I'll move this to a separate patch.

[akhuang]

Remove fno-use-ctor-homing flag

[jmorse]

David wrote:

think what I'm missing here: If -fno-standalone-debug is already in use/the default and is causing missing types because parts of the program are bulit without debug info, then I'm not sure what the rationale is for slicing -fstandalone-debug into a "has ctor homing" and a "doesn't have ctor homing" strategy. The same general design philosophy applies - that in both cases (about 4 cases in total now: types that aren't required to be complete, explicitly instantiated templates, vtables, and now ctor homing) the whole program must be compiled with debug info enabled for these DWARF size optimizations to be sound.

It's a matter of degree:

• Some types go missing, but due to the dllimport mechanism mentioned, all the important ones are retained,
• Switching to -fstandalone-debug increases the amount of DWARF by ~50% in experiments I've run, which for a {single-file-recompile, link, load-into-debugger} round trip will translate to an almost 50% increase in round-trip-time. (What with DWARF being the major part of linking and debugger-loading).

Thus the status quo (-fno-standalone-debug and closed-source libraries) hasn't been conceptually sounds, but it's given a "good enough" debugging experience without major round-trip-time penalty.

[akhuang]

In D106084#2897515, @jmorse wrote:

David wrote:

think what I'm missing here: If -fno-standalone-debug is already in use/the default and is causing missing types because parts of the program are bulit without debug info, then I'm not sure what the rationale is for slicing -fstandalone-debug into a "has ctor homing" and a "doesn't have ctor homing" strategy. The same general design philosophy applies - that in both cases (about 4 cases in total now: types that aren't required to be complete, explicitly instantiated templates, vtables, and now ctor homing) the whole program must be compiled with debug info enabled for these DWARF size optimizations to be sound.

It's a matter of degree:

• Some types go missing, but due to the dllimport mechanism mentioned, all the important ones are retained,
• Switching to -fstandalone-debug increases the amount of DWARF by ~50% in experiments I've run, which for a {single-file-recompile, link, load-into-debugger} round trip will translate to an almost 50% increase in round-trip-time. (What with DWARF being the major part of linking and debugger-loading).

Thus the status quo (-fno-standalone-debug and closed-source libraries) hasn't been conceptually sounds, but it's given a "good enough" debugging experience without major round-trip-time penalty.

Right, I think chromium on mac does the same thing (build with -fno-standalone-debug even though it drops some types, because -fstandalone-debug is too large).

[dblaikie]

In D106084#2897515, @jmorse wrote:

David wrote:

think what I'm missing here: If -fno-standalone-debug is already in use/the default and is causing missing types because parts of the program are bulit without debug info, then I'm not sure what the rationale is for slicing -fstandalone-debug into a "has ctor homing" and a "doesn't have ctor homing" strategy. The same general design philosophy applies - that in both cases (about 4 cases in total now: types that aren't required to be complete, explicitly instantiated templates, vtables, and now ctor homing) the whole program must be compiled with debug info enabled for these DWARF size optimizations to be sound.

It's a matter of degree:

• Some types go missing, but due to the dllimport mechanism mentioned, all the important ones are retained,
• Switching to -fstandalone-debug increases the amount of DWARF by ~50% in experiments I've run, which for a {single-file-recompile, link, load-into-debugger} round trip will translate to an almost 50% increase in round-trip-time. (What with DWARF being the major part of linking and debugger-loading).

Thus the status quo (-fno-standalone-debug and closed-source libraries) hasn't been conceptually sounds, but it's given a "good enough" debugging experience without major round-trip-time penalty.

I think it'd be unfortunate to split this hair in LLVM/Clang proper & feel like that sort of value tradeoff might be better suited in a downstream patch. (mostly because eventually it'd be good to get rid of the distinction between other type homing and ctor type homing entirely - there's already 3 categories of type homing under the existing category (type completeness, explicit template instantiations, and vtable based homing) & I don't think there's a good line to draw between those and ctor type homing - and module type homing (which I think I've already implemented &the is under -fno-standalone-debug, but no one's using modular code generation right now so it's not super interesting to anyone), maybe ThinLTO type homing (which would be a bit more robust than the others, since it has whole program-ish view)

[dblaikie]

Sounds like this is good for Google and Sony, and Apple doesn't use -fno-standalone-debug/-flimit-debug-info anyway, so probably about ready to move forward, then?

[akhuang]

yep, should be good now - I'll commit it soon

clang/include/clang/Basic/DebugInfoOptions.h

enum DebugInfoKind {
 
   /// Emit only debug info necessary for generating line number tables
   /// (-gline-tables-only).
   DebugLineTablesOnly,
 
   /// Limit generated debug info for classes to reduce size. This emits class
   /// type info only where the constructor is emitted, if it is a class that
   /// has a constructor.
+  /// FIXME: Consider combining this with LimitedDebugInfo.
   DebugInfoConstructor,
 
   /// Limit generated debug info to reduce size (-fno-standalone-debug). This
   /// emits forward decls for types that could be replaced with forward decls in
   /// the source code. For dynamic C++ classes type info is only emitted into
   /// the module that contains the classe's vtable.
   LimitedDebugInfo,
 

clang/lib/Driver/ToolChains/Clang.cpp

static codegenoptions::DebugInfoKind DebugLevelToInfoKind(const Arg &A) {
   if (A.getOption().matches(options::OPT_g0) ||
       A.getOption().matches(options::OPT_ggdb0))
     return codegenoptions::NoDebugInfo;
   if (A.getOption().matches(options::OPT_gline_tables_only) ||
       A.getOption().matches(options::OPT_ggdb1))
     return codegenoptions::DebugLineTablesOnly;
   if (A.getOption().matches(options::OPT_gline_directives_only))
     return codegenoptions::DebugDirectivesOnly;
-  return codegenoptions::LimitedDebugInfo;
+  return codegenoptions::DebugInfoConstructor;
 }
 
 static bool mustUseNonLeafFramePointerForTarget(const llvm::Triple &Triple) {
   switch (Triple.getArch()){
   default:
     return false;
   case llvm::Triple::arm:
   case llvm::Triple::thumb:
for (StringRef Value : A->getValues()) {
           TakeNextArg = true;
       } else if (Value.startswith("-gdwarf-")) {
         // "-gdwarf-N" options are not cc1as options.
         unsigned DwarfVersion = DwarfVersionNum(Value);
         if (DwarfVersion == 0) { // Send it onward, and let cc1as complain.
           CmdArgs.push_back(Value.data());
         } else {
           RenderDebugEnablingArgs(Args, CmdArgs,
-                                  codegenoptions::LimitedDebugInfo,
+                                  codegenoptions::DebugInfoConstructor,
                                   DwarfVersion, llvm::DebuggerKind::Default);
         }
       } else if (Value.startswith("-mcpu") || Value.startswith("-mfpu") ||
                  Value.startswith("-mhwdiv") || Value.startswith("-march")) {
         // Do nothing, we'll validate it later.
       } else if (Value == "-defsym") {
           if (A->getNumValues() != 2) {
             D.Diag(diag::err_drv_defsym_invalid_format) << Value;
if (IRInput || Args.hasArg(options::OPT_g_Group)) {
     DwarfFission = getDebugFissionKind(D, Args, SplitDWARFArg);
     if (DwarfFission != DwarfFissionKind::None &&
         !checkDebugInfoOption(SplitDWARFArg, Args, D, TC)) {
       DwarfFission = DwarfFissionKind::None;
       SplitDWARFInlining = false;
     }
   }
   if (const Arg *A = Args.getLastArg(options::OPT_g_Group)) {
-    DebugInfoKind = codegenoptions::LimitedDebugInfo;
+    DebugInfoKind = codegenoptions::DebugInfoConstructor;
 
     // If the last option explicitly specified a debug-info level, use it.
     if (checkDebugInfoOption(A, Args, D, TC) &&
         A->getOption().matches(options::OPT_gN_Group)) {
       DebugInfoKind = DebugLevelToInfoKind(*A);
       // For -g0 or -gline-tables-only, drop -gsplit-dwarf. This gets a bit more
       // complicated if you've disabled inline info in the skeleton CUs
       // (SplitDWARFInlining) - then there's value in composing split-dwarf and
if (!Args.hasFlag(options::OPT_gcolumn_info, options::OPT_gno_column_info,
     CmdArgs.push_back("-gno-column-info");
 
   // FIXME: Move backend command line options to the module.
   // If -gline-tables-only or -gline-directives-only is the last option it wins.
   if (const Arg *A = Args.getLastArg(options::OPT_gmodules))
     if (checkDebugInfoOption(A, Args, D, TC)) {
       if (DebugInfoKind != codegenoptions::DebugLineTablesOnly &&
           DebugInfoKind != codegenoptions::DebugDirectivesOnly) {
-        DebugInfoKind = codegenoptions::LimitedDebugInfo;
+        DebugInfoKind = codegenoptions::DebugInfoConstructor;
         CmdArgs.push_back("-dwarf-ext-refs");
         CmdArgs.push_back("-fmodule-format=obj");
       }
     }
 
   if (T.isOSBinFormatELF() && SplitDWARFInlining)
     CmdArgs.push_back("-fsplit-dwarf-inlining");
 
   // After we've dealt with all combinations of things that could
   // make DebugInfoKind be other than None or DebugLineTablesOnly,
   // figure out if we need to "upgrade" it to standalone debug info.
   // We parse these two '-f' options whether or not they will be used,
   // to claim them even if you wrote "-fstandalone-debug -gline-tables-only"
   bool NeedFullDebug = Args.hasFlag(
       options::OPT_fstandalone_debug, options::OPT_fno_standalone_debug,
       DebuggerTuning == llvm::DebuggerKind::LLDB ||
           TC.GetDefaultStandaloneDebug());
   if (const Arg *A = Args.getLastArg(options::OPT_fstandalone_debug))
     (void)checkDebugInfoOption(A, Args, D, TC);
 
-  if (DebugInfoKind == codegenoptions::LimitedDebugInfo) {
+  if (DebugInfoKind == codegenoptions::LimitedDebugInfo ||
+      DebugInfoKind == codegenoptions::DebugInfoConstructor) {
     if (Args.hasFlag(options::OPT_fno_eliminate_unused_debug_types,
                      options::OPT_feliminate_unused_debug_types, false))
       DebugInfoKind = codegenoptions::UnusedTypeInfo;
     else if (NeedFullDebug)
       DebugInfoKind = codegenoptions::FullDebugInfo;
   }
 
   if (Args.hasFlag(options::OPT_gembed_source, options::OPT_gno_embed_source,
if (!isNVPTX && Args.hasFlag(options::OPT__SLASH_GS, options::OPT__SLASH_GS_,
     CmdArgs.push_back(Args.MakeArgString(Twine(LangOptions::SSPStrong)));
   }
 
   // Emit CodeView if -Z7 or -gline-tables-only are present.
   if (Arg *DebugInfoArg = Args.getLastArg(options::OPT__SLASH_Z7,
                                           options::OPT_gline_tables_only)) {
     *EmitCodeView = true;
     if (DebugInfoArg->getOption().matches(options::OPT__SLASH_Z7))
-      *DebugInfoKind = codegenoptions::LimitedDebugInfo;
+      *DebugInfoKind = codegenoptions::DebugInfoConstructor;
     else
       *DebugInfoKind = codegenoptions::DebugLineTablesOnly;
   } else {
     *EmitCodeView = false;
   }
 
   const Driver &D = getToolChain().getDriver();
   EHFlags EH = parseClangCLEHFlags(D, Args);
void ClangAs::ConstructJob(Compilation &C, const JobAction &JA,
   codegenoptions::DebugInfoKind DebugInfoKind = codegenoptions::NoDebugInfo;
 
   if (SourceAction->getType() == types::TY_Asm ||
       SourceAction->getType() == types::TY_PP_Asm) {
     // You might think that it would be ok to set DebugInfoKind outside of
     // the guard for source type, however there is a test which asserts
     // that some assembler invocation receives no -debug-info-kind,
     // and it's not clear whether that test is just overly restrictive.
-    DebugInfoKind = (WantDebug ? codegenoptions::LimitedDebugInfo
+    DebugInfoKind = (WantDebug ? codegenoptions::DebugInfoConstructor
                                : codegenoptions::NoDebugInfo);
     // Add the -fdebug-compilation-dir flag if needed.
     addDebugCompDirArg(Args, CmdArgs, C.getDriver().getVFS());
 
     addDebugPrefixMapArg(getToolChain().getDriver(), Args, CmdArgs);
 
     // Set the AT_producer to the clang version when using the integrated
     // assembler on assembly source files.

clang/test/CodeGenCXX/debug-info-template-deduction-guide.cpp

 // RUN: %clang -S -emit-llvm -target x86_64-unknown_unknown -g %s -o - -std=c++1z | FileCheck %s
 
 // Verify that we don't crash when emitting debug information for objects
 // created from a deduced template specialization.
 
 template <class T>
 struct S {
   S(T) {}
 };
 
-// CHECK: !DIGlobalVariable(name: "s1"
-// CHECK-SAME: type: [[TYPE_NUM:![0-9]+]]
-// CHECK: !DIGlobalVariable(name: "s2"
-// CHECK-SAME: type: [[TYPE_NUM]]
-// CHECK: [[TYPE_NUM]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S<int>",
+// CHECK-DAG: !DIGlobalVariable(name: "s1"{{.*}} type: [[TYPE_NUM:![0-9]+]]
+// CHECK-DAG: !DIGlobalVariable(name: "s2"{{.*}} type: [[TYPE_NUM]]
+// CHECK-DAG: [[TYPE_NUM]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S<int>",
 S s1(42);
 S<int> s2(42);

clang/test/Driver/cl-options.c

 
 // RUN: %clang_cl /Zc:dllexportInlines- /c -### -- %s 2>&1 | FileCheck -check-prefix=NoDllExportInlines %s
 // NoDllExportInlines: "-fno-dllexport-inlines"
 // RUN: %clang_cl /Zc:dllexportInlines /c -### -- %s 2>&1 | FileCheck -check-prefix=DllExportInlines %s
 // DllExportInlines-NOT: "-fno-dllexport-inlines"
 
 // RUN: %clang_cl /Zi /c -### -- %s 2>&1 | FileCheck -check-prefix=Zi %s
 // Zi: "-gcodeview"
-// Zi: "-debug-info-kind=limited"
+// Zi: "-debug-info-kind=constructor"
 
 // RUN: %clang_cl /Z7 /c -### -- %s 2>&1 | FileCheck -check-prefix=Z7 %s
 // Z7: "-gcodeview"
-// Z7: "-debug-info-kind=limited"
+// Z7: "-debug-info-kind=constructor"
 
 // RUN: %clang_cl -gline-tables-only /c -### -- %s 2>&1 | FileCheck -check-prefix=ZGMLT %s
 // ZGMLT: "-gcodeview"
 // ZGMLT: "-debug-info-kind=line-tables-only"
 
 // RUN: %clang_cl /c -### -- %s 2>&1 | FileCheck -check-prefix=BreproDefault %s
 // BreproDefault: "-mincremental-linker-compatible"
 
 // RUN: %clang_cl /Brepro- /Brepro /c '-###' -- %s 2>&1 | FileCheck -check-prefix=Brepro %s
 // Brepro-NOT: "-mincremental-linker-compatible"
 
 // RUN: %clang_cl /Brepro /Brepro- /c '-###' -- %s 2>&1 | FileCheck -check-prefix=Brepro_ %s
 // Brepro_: "-mincremental-linker-compatible"
 
 // This test was super sneaky: "/Z7" means "line-tables", but "-gdwarf" occurs
 // later on the command line, so it should win. Interestingly the cc1 arguments
 // came out right, but had wrong semantics, because an invariant assumed by
 // CompilerInvocation was violated: it expects that at most one of {gdwarfN,
 // line-tables-only} appear. If you assume that, then you can safely use
 // Args.hasArg to test whether a boolean flag is present without caring
 // where it appeared. And for this test, it appeared to the left of -gdwarf
 // which made it "win". This test could not detect that bug.
 // RUN: %clang_cl /Z7 -gdwarf /c -### -- %s 2>&1 | FileCheck -check-prefix=Z7_gdwarf %s
 // Z7_gdwarf: "-gcodeview"
-// Z7_gdwarf: "-debug-info-kind=limited"
+// Z7_gdwarf: "-debug-info-kind=constructor"
 // Z7_gdwarf: "-dwarf-version=4"
 
 // RUN: %clang_cl -fmsc-version=1800 -TP -### -- %s 2>&1 | FileCheck -check-prefix=CXX11 %s
 // CXX11: -std=c++11
 
 // RUN: %clang_cl -fmsc-version=1900 -TP -### -- %s 2>&1 | FileCheck -check-prefix=CXX14 %s
 // CXX14: -std=c++14
 

clang/test/Driver/clang-g-opts.c

 // RUN: %clang -### -S %s -g0 -g -target i686-pc-openbsd 2>&1 \
 // RUN:             | FileCheck --check-prefix=CHECK-WITH-G-DWARF2 %s
 // RUN: %clang -### -S %s -g0 -g -target x86_64-pc-freebsd10.0 2>&1 \
 // RUN:             | FileCheck --check-prefix=CHECK-WITH-G-DWARF2 %s
 // RUN: %clang -### -S %s -g0 -g -target i386-pc-solaris 2>&1 \
 // RUN:             | FileCheck --check-prefix=CHECK-WITH-G-DWARF2 %s
 
 // CHECK-WITHOUT-G-NOT: -debug-info-kind
-// CHECK-WITH-G: "-debug-info-kind=limited"
+// CHECK-WITH-G: "-debug-info-kind=constructor"
 // CHECK-WITH-G: "-dwarf-version=4"
 // CHECK-WITH-G-DWARF2: "-dwarf-version=2"
 
 // CHECK-WITH-G-STANDALONE: "-debug-info-kind=standalone"
 // CHECK-WITH-G-STANDALONE: "-dwarf-version=2"

clang/test/Driver/cuda-dwarf-2.cu

 // RUN:   FileCheck %s -check-prefix HAS_DEBUG
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 %s -ggdb1 2>&1 | \
 // RUN:   FileCheck %s -check-prefix HAS_DEBUG
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 %s -gline-tables-only -O2 --cuda-noopt-device-debug 2>&1 | \
 // RUN:   FileCheck %s -check-prefix HAS_DEBUG
 
 // HAS_DEBUG-NOT: warning: debug
 // HAS_DEBUG: "-fcuda-is-device"
-// HAS_DEBUG-SAME: "-debug-info-kind={{limited|line-tables-only}}"
+// HAS_DEBUG-SAME: "-debug-info-kind={{constructor|line-tables-only}}"
 // HAS_DEBUG-SAME: "-dwarf-version=2"
 // HAS_DEBUG: ptxas
 // HAS_DEBUG-SAME: "-g"
 // HAS_DEBUG-SAME: "--dont-merge-basicblocks"
 // HAS_DEBUG-SAME: "--return-at-end"
 // HAS_DEBUG: fatbinary
 // HAS_DEBUG-SAME: "-g"
 

clang/test/Driver/debug-options-as.c

 // GGDB0-NOT: -debug-info-kind=
 
 // Check to make sure clang with -g on a .s file gets passed.
 // rdar://9275556
 // RUN: %clang -### -c -integrated-as -g -x assembler %s 2>&1 \
 // RUN:   | FileCheck %s
 //
 // CHECK: "-cc1as"
-// CHECK: "-debug-info-kind=limited"
+// CHECK: "-debug-info-kind=constructor"
 
 // Check to make sure clang with -g on a .s file gets passed -dwarf-debug-producer.
 // rdar://12955296
 // RUN: %clang -### -c -integrated-as -g -x assembler %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=P %s
 //
 // P: "-cc1as"
 // P: "-dwarf-debug-producer"

clang/test/Driver/debug-options.c

 // GLIO_ONLY: "-debug-info-kind=line-directives-only"
 // GLIO_ONLY-NOT: "-dwarf-ext-refs"
 //
 // GLIO_ONLY_DWARF2: "-cc1"
 // GLIO_ONLY_DWARF2: "-debug-info-kind=line-directives-only"
 // GLIO_ONLY_DWARF2: "-dwarf-version=2"
 //
 // G_ONLY: "-cc1"
-// G_ONLY: "-debug-info-kind=limited"
+// G_ONLY: "-debug-info-kind=constructor"
 //
 // These tests assert that "-gline-tables-only" "-g" uses the latter,
 // but otherwise not caring about the DebugInfoKind.
 // G_ONLY_DWARF2: "-cc1"
-// G_ONLY_DWARF2: "-debug-info-kind={{standalone|limited}}"
+// G_ONLY_DWARF2: "-debug-info-kind={{standalone|constructor}}"
 // G_ONLY_DWARF2: "-dwarf-version=2"
 //
 // G_STANDALONE: "-cc1"
 // G_STANDALONE: "-debug-info-kind=standalone"
 // G_LIMITED: "-cc1"
-// G_LIMITED: "-debug-info-kind=limited"
+// G_LIMITED: "-debug-info-kind=constructor"
 // G_DWARF2: "-dwarf-version=2"
 // G_DWARF4: "-dwarf-version=4"
 //
 // G_GDB:  "-debugger-tuning=gdb"
 // G_LLDB: "-debugger-tuning=lldb"
 // G_SCE:  "-debugger-tuning=sce"
 // G_DBX:  "-debugger-tuning=dbx"
 //

 // NOFDTS-NOT: "-mllvm" "-generate-type-units"
 // NOFDTSE-NOT: error: unsupported option '-fdebug-types-section' for target 'x86_64-apple-darwin'
 //
 // CI-NOT: "-gno-column-info"
 //
 // NOCI: "-gno-column-info"
 //
 // GEXTREFS: "-dwarf-ext-refs" "-fmodule-format=obj"
-// GEXTREFS: "-debug-info-kind={{standalone|limited}}"
+// GEXTREFS: "-debug-info-kind={{standalone|constructor}}"
 
 // RUN: not %clang -cc1 -debug-info-kind=watkind 2>&1 | FileCheck -check-prefix=BADSTRING1 %s
 // BADSTRING1: error: invalid value 'watkind' in '-debug-info-kind=watkind'
 // RUN: not %clang -cc1 -debugger-tuning=gmodal 2>&1 | FileCheck -check-prefix=BADSTRING2 %s
 // BADSTRING2: error: invalid value 'gmodal' in '-debugger-tuning=gmodal'
 
 // RUN: %clang -### -fdebug-macro    %s 2>&1 | FileCheck -check-prefix=MACRO %s
 // RUN: %clang -### -fno-debug-macro %s 2>&1 | FileCheck -check-prefix=NOMACRO %s

 // RUN: %clang -### -g -fno-eliminate-unused-debug-types -c %s 2>&1 \
 // 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: "-debug-info-kind={{constructor|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

clang/test/Driver/integrated-as.s

 // XA_INCLUDE1: cc1as
 // XA_INCLUDE1: "-I" "foo_dir"
 
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -Xassembler -Ifoo_dir 2>&1 | FileCheck --check-prefix=XA_INCLUDE2 %s
 // XA_INCLUDE2: cc1as
 // XA_INCLUDE2: "-Ifoo_dir"
 
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -gdwarf-4 -gdwarf-2 2>&1 | FileCheck --check-prefix=DWARF2 %s
-// DWARF2: "-debug-info-kind=limited" "-dwarf-version=2"
+// DWARF2: "-debug-info-kind=constructor" "-dwarf-version=2"
 
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -gdwarf-3 2>&1 | FileCheck --check-prefix=DWARF3 %s
-// DWARF3: "-debug-info-kind=limited" "-dwarf-version=3"
+// DWARF3: "-debug-info-kind=constructor" "-dwarf-version=3"
 
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -gdwarf-4 2>&1 | FileCheck --check-prefix=DWARF4 %s
-// DWARF4: "-debug-info-kind=limited" "-dwarf-version=4"
+// DWARF4: "-debug-info-kind=constructor" "-dwarf-version=4"
 
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -Xassembler -gdwarf-2 2>&1 | FileCheck --check-prefix=DWARF2XASSEMBLER %s
-// DWARF2XASSEMBLER: "-debug-info-kind=limited" "-dwarf-version=2"
+// DWARF2XASSEMBLER: "-debug-info-kind=constructor" "-dwarf-version=2"
 
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -Wa,-gdwarf-2 2>&1 | FileCheck --check-prefix=DWARF2WA %s
-// DWARF2WA: "-debug-info-kind=limited" "-dwarf-version=2"
+// DWARF2WA: "-debug-info-kind=constructor" "-dwarf-version=2"
 
 // A dwarf version number that driver can't parse is just stuffed in.
 // RUN: %clang -### -target x86_64--- -c -integrated-as %s -Wa,-gdwarf-huh 2>&1 | FileCheck --check-prefix=BOGODWARF %s
 // BOGODWARF: "-gdwarf-huh"
 
 // RUN: %clang -### -target x86_64--- -x assembler -c -integrated-as %s -I myincludedir 2>&1 | FileCheck --check-prefix=INCLUDEPATH %s
 // INCLUDEPATH: "-I" "myincludedir"
 

clang/test/Driver/myriad-toolchain.c

 // RUN: %clang -stdlib=libc++ -### -target sparcel-myriad -S -x c++ %s 2>&1 | FileCheck %s -check-prefix=LIBCXX
 // LIBCXX: "-internal-isystem" "{{.*}}/../include/c++/v1"
 
 // RUN: %clang -target sparc-myriad -### -nostdlib %s 2>&1 | FileCheck %s --check-prefix=NOSTDLIB
 // NOSTDLIB-NOT: crtbegin.o
 // NOSTDLIB-NOT: "-lc"
 
 // RUN: %clang -### -c -g %s -target sparc-myriad 2>&1 | FileCheck -check-prefix=G_SPARC %s
-// G_SPARC: "-debug-info-kind=limited" "-dwarf-version=2"
+// G_SPARC: "-debug-info-kind=constructor" "-dwarf-version=2"
 
 // RUN: %clang -### -c %s -target sparc-myriad-rtems -fuse-init-array 2>&1 \
 // RUN: | FileCheck -check-prefix=USE-INIT-ARRAY %s
 // USE-INIT-ARRAY-NOT: argument unused

clang/test/Driver/openmp-offload-gpu.c

 // RUN:   | FileCheck -check-prefix=HAS_DEBUG %s
 // RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s -gline-tables-only 2>&1 \
 // RUN:   | FileCheck -check-prefix=HAS_DEBUG %s
 // RUN:   %clang -### -no-canonical-prefixes -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target -march=sm_60 %s -ggdb1 -O2 --cuda-noopt-device-debug 2>&1 \
 // RUN:   | FileCheck -check-prefix=HAS_DEBUG %s
 
 // HAS_DEBUG-NOT: warning: debug
 // HAS_DEBUG: "-triple" "nvptx64-nvidia-cuda"
-// HAS_DEBUG-SAME: "-debug-info-kind={{limited|line-tables-only}}"
+// HAS_DEBUG-SAME: "-debug-info-kind={{constructor|line-tables-only}}"
 // HAS_DEBUG-SAME: "-dwarf-version=2"
 // HAS_DEBUG-SAME: "-fopenmp-is-device"
 // HAS_DEBUG: ptxas
 // HAS_DEBUG-SAME: "-g"
 // HAS_DEBUG-SAME: "--dont-merge-basicblocks"
 // HAS_DEBUG-SAME: "--return-at-end"
 // HAS_DEBUG: nvlink
 // HAS_DEBUG-SAME: "-g"

clang/test/Driver/split-debug.c

 /// Test -gsplit-dwarf and -gsplit-dwarf={split,single}.
 
 /// Interaction with -g (-g2).
 // RUN: %clang -### -c -target x86_64 -g -gsplit-dwarf %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 // RUN: %clang -### -c -target x86_64 -g2 -gsplit-dwarf %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 /// -gsplit-dwarf=split is equivalent to -gsplit-dwarf.
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 
 // INLINE:     "-fsplit-dwarf-inlining"
 // NOINLINE-NOT: "-fsplit-dwarf-inlining"
-// SPLIT:      "-debug-info-kind=limited"
+// SPLIT:      "-debug-info-kind=constructor"
 // SPLIT-SAME: "-ggnu-pubnames"
 // SPLIT-SAME: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
 // RUN: %clang -### -c -target wasm32 -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=SPLIT
 // RUN: %clang -### -c -target amdgcn-amd-amdhsa -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=SPLIT
 
 /// -gsplit-dwarf is a no-op on a non-ELF platform.
 // RUN: %clang -### -c -target x86_64-apple-darwin  -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=DARWIN

 // IR:      "-ggnu-pubnames"
 // IR-SAME: "-split-dwarf-file" "{{.*}}.dwo" "-split-dwarf-output" "{{.*}}.dwo"
 
 /// -gno-split-dwarf disables debug fission.
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf -g -gno-split-dwarf %s 2>&1 | FileCheck %s --check-prefix=NOSPLIT
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=single -g -gno-split-dwarf %s 2>&1 | FileCheck %s --check-prefix=NOSPLIT
 // RUN: %clang -### -c -target x86_64 -gno-split-dwarf -g -gsplit-dwarf %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 
-// NOSPLIT:     "-debug-info-kind=limited"
+// NOSPLIT:     "-debug-info-kind=constructor"
 // NOSPLIT-NOT: "-ggnu-pubnames"
 // NOSPLIT-NOT: "-split-dwarf
 
 /// Test -gsplit-dwarf=single.
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=single -g %s 2>&1 | FileCheck %s --check-prefix=SINGLE
 
-// SINGLE: "-debug-info-kind=limited"
+// SINGLE: "-debug-info-kind=constructor"
 // SINGLE: "-split-dwarf-file" "split-debug.o"
 // SINGLE-NOT: "-split-dwarf-output"
 
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=single -g -o %tfoo.o %s 2>&1 | FileCheck %s --check-prefix=SINGLE_WITH_FILENAME
 
 // SINGLE_WITH_FILENAME: "-split-dwarf-file" "{{.*}}foo.o"
 // SINGLE_WITH_FILENAME-NOT: "-split-dwarf-output"
 
 /// Without -c, clang performs linking as well. The output is unchanged.
 // RUN: %clang -### -target x86_64-unknown-linux-gnu -gsplit-dwarf -g %s -o ignore.d 2>&1 | FileCheck %s --check-prefix=SPLIT
 
 /// -fsplit-dwarf-inlining
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -fsplit-dwarf-inlining %s 2>&1 | FileCheck %s --check-prefixes=INLINE,SPLIT
 
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -gno-pubnames %s 2>&1 | FileCheck %s --check-prefixes=NOPUBNAMES
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -gno-gnu-pubnames %s 2>&1 | FileCheck %s --check-prefixes=NOPUBNAMES
-// NOPUBNAMES:      "-debug-info-kind=limited"
+// NOPUBNAMES:      "-debug-info-kind=constructor"
 // NOPUBNAMES-NOT:  "-ggnu-pubnames"
 // NOPUBNAMES-SAME: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
 /// Invoke objcopy if not using the integrated assembler.
 // RUN: %clang -### -c -target x86_64-unknown-linux-gnu -fno-integrated-as -gsplit-dwarf -g %s 2>&1 | FileCheck %s --check-prefix=OBJCOPY
 // OBJCOPY:      objcopy{{(.exe)?}}" "--extract-dwo"
 // OBJCOPY-NEXT: objcopy{{(.exe)?}}" "--strip-dwo"
 

lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp

protected:
   friend class Friend;
   int m_protected;
 };
 } // namespace MemberTest
 
 int main() {
   MemberTest::Base B1;
   B1.Get();
+  // Create instance of C1 so that it has debug info (due to constructor
+  // homing).
+  MemberTest::Class C1;
   MemberTest::Class::StaticMemberFunc(1, 10, 2);
   return 0;
 }