[symbolizer] Parse DW_TAG_variable DIs to show line info for globals

[hctim]

Summary

Currently, llvm-symbolizer doesn't like to parse .debug_info in order to
show the line info for global variables. addr2line does this. In the
future, I'm looking to migrate AddressSanitizer off of internal metadata
over to using debuginfo, and this is predicated on being able to get the
line info for global variables.

This patch adds the requisite support for getting the line info from the
.debug_info section for symbolizing global variables. This only happens
when you ask for a global variable to be symbolized as data.

[tschuett]

llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h

248 ↗

(On Diff #422014)

Are you sure about your map and set types?
https://llvm.org/docs/ProgrammersManual.html#other-set-like-container-options

[hctim]

.

llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h

248 ↗

(On Diff #422014)

thanks, changed to set/map given that bionic's libc.so has 10.5k DW_TAG_variables, so DenseSet/DenseMap doesn't seem like the right structure either.

[tschuett]

I do not want to bother you at all:
https://llvm.org/docs/ProgrammersManual.html#map

[hctim]

In D123538#3443755, @tschuett wrote:

I do not want to bother you at all:
https://llvm.org/docs/ProgrammersManual.html#map

Is there a better data structure you'd recommend? I picked the map based on the following:

std::map is most useful when your keys or values are very large

given the 10.5k DW_TAG_variables in bionic libc.so and the quote from DenseMap:

it will waste a lot of space if your keys or values are large

Am I misreading the above sentence to mean "if the count of keys is huge", and the intended meaning is "if sizeof(key) is huge"?

[tschuett]

Unfortunately not. set and map seem to be very malloc heavy. I could not find any great alternatives in the LLVM manual.

[jhenderson]

I think this needs a doc update?

FYI: I've not looked at the parts of this patch that are in DebugInfo/DWARF. Someone with more familiarity with the area should probably review it (I can if nobody else is around - adding @dblaikie who may be a good shout).

llvm/test/tools/llvm-symbolizer/data-location.s

16 ↗

(On Diff #422021)

One of the purposes of the cross-project-tests project was to make it easier to test llvm-symbolizer without having to resort to canned binaries or canned YAML blobs like below. By writing the test there, you can use clang and lld directly and consequently start from a much more understandable .c file.

That being said, I wonder if you'd be better off hand-crafting this YAML. It doesn't seem likely to be that complicated to write some .debug_info that has the property you want using yaml2obj's DWARF support, if I follow the required behaviour correctly. There are already some good examples of similar bits. The advantage with using yaml like that is that you can keep it tightly focused on what is important, omitting the various components of the object that are unrelated to the test (e.g. .eh_frame).

[hctim]

llvm/test/tools/llvm-symbolizer/data-location.s

16 ↗

(On Diff #422021)

I had a quick look at cross-project-tests, and didn't find any examples where llvm-symbolizer was currently being tests there, and I think it's out of scope for this patch.

The right way to test this is to invoke clang and run llvm-symbolizer as the output.

My problem with hand-crafting is that it's:

a) Very time consuming, looking into it further I'd have to read a lot more about the ELF spec for .debug_abbrev, .debug_info, and .debug_line to understand what headers are needed.

b) Hard to change. If someone introduces some new feature, then they have to go through the same "understand nuance of ELF" to just modify my test so that it passes. It's much easier for someone to go "hey, just need to recompile this example file and make sure the new golden file passes the existing test".

[dblaikie]

it will waste a lot of space if your keys or values are large

Am I misreading the above sentence to mean "if the count of keys is huge", and the intended meaning is "if sizeof(key) is huge"?

That's correct - dense* may perform poorly/use excess memory if sizeof(key) is large.

llvm/test/tools/llvm-symbolizer/data-location.s

16 ↗

(On Diff #422021)

(re: cross-project-tests: They must not be used as a replacement for individual project testing - but for added feature/cross-project coverage if there's important interactions between components. But an LLVM patch should still have an LLVM test, a Clang patch with a Clang test, etc - and optionally some additional cross-project feature testing)

re: hand crafting: Yeah, I'm not a super fan of doing that, until/unless yaml2obj can really simplify writing DWARF down to not needing to write abbreviations, multiple sections, attribute forms, etc.

Though is there any reason this test needs a function in it? & any reason it needs two integers?

[hctim]

.

llvm/test/tools/llvm-symbolizer/data-location.s

16 ↗

(On Diff #422021)

I updated the test a little and added some more of what I was hoping for.

One global in data, one in bss, one as a function-static global and a string (this patch now depends on D123534).

[jhenderson]

llvm/test/tools/llvm-symbolizer/data-location.s

7 ↗

(On Diff #423180)

It might be useful to add comments about what is special about each of these cases (i.e. data/bss/function-static/string) or even name the variables along those lines to directly imply their purpose. That way, if the test is ever rewritten, it's easy to understand why each example exists and what is important about it. That being said, is there actually a difference between them for the testing purposes? What do they actually exercise in the code changes? (I haven't looked at the code changes to understand this).

16 ↗

(On Diff #422021)

(re: cross-project-tests: They must not be used as a replacement for individual project testing - but for added feature/cross-project coverage if there's important interactions between components. But an LLVM patch should still have an LLVM test, a Clang patch with a Clang test, etc - and optionally some additional cross-project feature testing)

That is one purpose for why I created this testsuite, but the other was for using tools to generate test inputs at runtime, such as clang or lld. In the original thread, I even discussed llvm-symbolizer as a concrete example (using LLD in that particular case, in the same manner as one might use llvm-mc for generating test input at test time, because creating canned test inputs means they're not easily maintainable). There are no current examples of this yet though.

[hctim]

Update

llvm/test/tools/llvm-symbolizer/data-location.s

7 ↗

(On Diff #423180)

Renamed them (and made the test less in need of massaging if things change). They're individually useful because they're different types of global variables, located in different places.

[dblaikie]

llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h

248 ↗

(On Diff #422014)

I don't believe the number of elements is an argument against the dense data structures - could you help explain/understand the connection there?

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1267–1277 ↗

(On Diff #423732)

Should this logic live in getCompileUnitForAddress insetad of here? (at least given the name, it sounds like it's something getCompileUnitForAddress should handle - but perhaps it should be renamed to be only about function addresses, and the variable walk could/should remain here?)

(awkwardly: LLVM's debug_aranges (Clang doesn't emit these by default anyway, so it's not likely to be much of an issue in the wild) would be sufficient to answer this query, but GCC does not include globals in debug_aranges, so they probably can't be relied upon unfortunately (unfortunate that Clang pays the cost when it emits them, but consumers can't rely on them) - and personally I'd rather we (DWARF in general) move away from aranges anyway, since (apart from this unreliable global variable case) they're covered by CU level high/low/ranges anyway)

1270–1271 ↗

(On Diff #423732)

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

743 ↗

(On Diff #423732)

Walking the entire DIE tree seems expensive - could this prune any branches? (such as when descending into a type DIE? (DW_TAG_*_type))

744 ↗

(On Diff #423732)

maybe DWARFDie supports range-based for loop now?

779–781 ↗

(On Diff #423732)

Rather than doing count + insert this should probably call insert up-front and inspect the return value to see if the insert happened, or if the value was already present - then if it happened, do the update.

784–786 ↗

(On Diff #423732)

This should probably use find rather than count+[] to avoid doing two lookups.

llvm/test/tools/llvm-symbolizer/data-location.s

16 ↗

(On Diff #422021)

(this might be shorter/simpler to read as assembly, rather than yaml?)

[hctim]

llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h

248 ↗

(On Diff #422014)

changed, thanks for clarifying before

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

744 ↗

(On Diff #423732)

Neat!

llvm/test/tools/llvm-symbolizer/data-location.s

16 ↗

(On Diff #422021)

(this might be shorter/simpler to read as assembly, rather than yaml?)

Originally that's what I thought of doing, but llvm-symbolizer doesn't play nicely with objfiles because the symbol addr is a section offset, so f is .text+0x0 and data_global is .data+0x0, and llvm-symbolizer only spits out one of them.

[hctim]

.

[hctim]

minor fix

[hctim]

XCOFF/print-linenumber.test	depends on the fact that symbolizing '0x0' should pull it from .text, even if there's a global variable also at '0x0'. This is why (as above) I don't think objfiles are a good test case for llvm-symbolizer, as an address alone can point to multiple symbolizable things.

So, now we specifically only do this with the 'DATA 0x0' pathways.

[jhenderson]

llvm/include/llvm/DebugInfo/DWARF/DWARFUnit.h

248–249 ↗

(On Diff #424324)

Nit: I don't think you need llvm:: here - we're already inside the llvm namespace.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1040–1042 ↗

(On Diff #424324)

I might be wrong, but I feel like I've heard of cases where .debug_aranges didn't cover all functions either. Indeed, our internal tool always searches both aranges and the CUs directly when looking up an address. (Not suggesting a change in this patch necessarily though).

1043 ↗

(On Diff #424324)

Could you avoid using auto here, please: the type isn't obvious, so it can be a little confusing, especially as my natural assumption was that this was a DWARFCompileUnit *, but the below cast indicates it isn't.

The previous code in getLineInfoForAddress used normal_units not compile_units. Why the change?

llvm/test/tools/llvm-symbolizer/data-location.s

7 ↗

(On Diff #423180)

They're individually useful because they're different types of global variables, located in different places.

Right, but are they located in differenet places within the DWARF? In other words, are any different code paths actually exercised this way?

Tangentially related: is one of the cases missing from the debug_aranges, so that the fallback code is exercised?

[hctim]

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1040–1042 ↗

(On Diff #424324)

ack, thanks for the colour

1043 ↗

(On Diff #424324)

Could you avoid using auto here, please: the type isn't obvious, so it can be a little confusing, especially as my natural assumption was that this was a DWARFCompileUnit *, but the below cast indicates it isn't.

Done

The previous code in getLineInfoForAddress used normal_units not compile_units. Why the change?

Either worked in my case, I figured compile_units was a better touch point because DW_TAG_variable seem to all be a child of a DW_TAG_compile_unit, and the implementaion point DWARFContext::getCompileUnitForAddress specifically mentions returning a CompileUnit. And, it seems like compile_units() is a subset of normal_units().

llvm/test/tools/llvm-symbolizer/data-location.s

7 ↗

(On Diff #423180)

Right, but are they located in differenet places within the DWARF? In other words, are any different code paths actually exercised this way?

No, bss_global and data_global are functionally here. The reason why I have them both here is because if you compile the source file to an object rather than a DSO, you end up with bad address lookups because bss_global and data_global are both at address 0x0 (just in different sections). I figured this would give some amount of posterity here about why it's a DSO, I know that I was pretty surprised there wasn't a great way to test it.

Maybe a comment is a better way to go about it. Let me know what you think.

Tangentially related: is one of the cases missing from the debug_aranges, so that the fallback code is exercised?

All of them are missing from the debug_aranges :)

[hctim]

Fix a small ordering bug, update with comments.

[jhenderson]

llvm/test/tools/llvm-symbolizer/data-location.s

7 ↗

(On Diff #423180)

As things stand, if I came to this test, I'd consider dropping vataiables that appear to be in the same place in the debug info, so a comment is probably needed saying what coverage they provide.

[hctim]

Update test, rebase off of string debuginfo.

[hctim]

(restoring after uploading the diff for D123534 here accidentally)

[hctim]

(restoring after uploading the diff for D123534 here accidentally)

[jhenderson]

llvm/test/tools/llvm-symbolizer/data-location.yaml

46 ↗

(On Diff #426177)

Nit

[hctim]

(comment)

llvm/test/tools/llvm-symbolizer/data-location.s

7 ↗

(On Diff #423180)

Done, and also made this patch no longer depend on D123534.

[jhenderson]

Okay, nothing else from me, but @dblaikie or another debuginfo person should review it too.

[dblaikie]

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1044 ↗

(On Diff #428538)

Might be worth a more precise statement here - at least my understanding is that GCC never puts global variables in aranges and clang always does (but it's not possible to differentiate the situations, making aranges untrustworthy for this query - so the code here is correct if it's got to handle GCC, not suggesting any code change, but maybe more info in the comment to point to GCC for a concrete example of the issue)

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

769–783 ↗

(On Diff #428538)

Are there any examples of global merge where this might not be correct?

Like if a global was described as "addrx, 5, add" (eg: 5 beyond this address) then only looking at the first operation might mis-conclude that the variable is at this address when it's at 5 bytes past this address - and some other variable is at this address)

LLVM has a "global merge" optimization that might cause something like this. Let's see if I can create an example.

Ah, yeah, here we go:

static int x;
static int y;
int *f(bool b) { return b ? &x : &y; }

$ clang++-tot -O3 merge.cpp -c -g -target aarch64-linux-gnuabi -mllvm -global-merge-ignore-single-use && llvm-dwarfdump-tot merge.o | grep DW_AT_location
                DW_AT_location  (DW_OP_addrx 0x0)
                DW_AT_location  (DW_OP_addrx 0x0, DW_OP_plus_uconst 0x4)

(the -global-merge-ignore-single-use is to simplify the test case - without that it could still be tickled with a more complicated example - seems we only enable global merge on ARM 32 and 64 bit due to the higher register pressure there, by the sounds of it)

I'm guessing this patch would overwrite the VariableDieMap entry for the first global with the second one so queries for the first address would result in the second DIE and queries for the second address wouldn't give any result?

Hmm, also - how does this handle queries that aren't at exactly the starting address of the variable? Presumably the DW_AT_type of the DW_TAG_global_variable would have to be inspected to find the size of the variable starting at the address, and any query in that range should be successful?

[hctim]

Patch update.

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

769–783 ↗

(On Diff #428538)

I've added some handling for the DW_OP_plus_uconst. Unfortunately I didn't find any generic existing handling for the expression evaluation (which surprised me, maybe I just suck at looking), so I'm just making the assumption that global variable addresses aren't described using DW_OP_plus or anything else...

Fixed it up to now provide line info when you provide an address halfway through a symbol. Good thing there wasn't a big impact in D123534 about keeping the string sizes around :). Worst case (if the type info sucks) we just only accept the precise start addresses of the symbols.

[dblaikie]

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

769–783 ↗

(On Diff #428538)

Probably worth maybe /only/ matching these expressions, then, rather than currently it's matching any expression that starts with addr, or addr+plus? Even if that's followed by any other garbage that would be ignored (& so the expression would be misinterpreted)

There's probably no expression evaluation logic in LLVM's libDebugInfoDWARF - there's no need to evaluate expressions when symbolizing, and dwarfdump just wants to dump it, not compute the resulting value. (some similar code exists in lldb that would do evaluation).

[hctim]

Explicitly only match 'DW_OP_addr[x] [+ DW_OP_plus_uconst]'

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

769–783 ↗

(On Diff #428538)

Sure, done.

[dblaikie]

Seems OK

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1040–1041 ↗

(On Diff #430509)

llvm/lib/DebugInfo/DWARF/DWARFDie.cpp

1159 ↗

(On Diff #430509)

Could be written as None (similarly for a couple of other cases above)

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

779–780 ↗

(On Diff #430509)

Maybe flesh out this comment to explain that it doesn't support the full generality of DWARF expressions (maybe some note about how "here's where to add more expression parsing functionality if/when needed/more interesting cases are discovered") but covers what LLVM producers currently at least. (maybe even point to the source code in LLVM (look around in lib/CodeGen/AsmPrinter to find where these addresses are created, maybe it'd be easy enough to cross-reference these two bits of code to see that they cover each other)

795–798 ↗

(On Diff #430509)

Maybe swap this around to reduce indentation/conditionality:

[hctim]

David's comments.

clang/lib/CodeGen/CGDebugInfo.h

public:
   void EmitUsingDecl(const UsingDecl &UD);
 
   /// Emit C++ using-enum declaration.
   void EmitUsingEnumDecl(const UsingEnumDecl &UD);
 
   /// Emit an @import declaration.
   void EmitImportDecl(const ImportDecl &ID);
 
+  /// Create and attach debuginfo to a the provided string literal GV.
+  void AddStringLiteralDebugInfo(llvm::GlobalVariable *GV, StringRef Name,
+                                 const StringLiteral *S);
+
   /// Emit C++ namespace alias.
   llvm::DIImportedEntity *EmitNamespaceAlias(const NamespaceAliasDecl &NA);
 
   /// Emit record type's standalone debug info.
   llvm::DIType *getOrCreateRecordType(QualType Ty, SourceLocation L);
 
   /// Emit an Objective-C interface type standalone debug info.
   llvm::DIType *getOrCreateInterfaceType(QualType Ty, SourceLocation Loc);

clang/lib/CodeGen/CGDebugInfo.cpp

 std::string CGDebugInfo::GetName(const Decl *D, bool Qualified) const {
   std::string Name;
   llvm::raw_string_ostream OS(Name);
   const NamedDecl *ND = dyn_cast<NamedDecl>(D);
   if (!ND)
     return Name;
   codegenoptions::DebugTemplateNamesKind TemplateNamesKind =
       CGM.getCodeGenOpts().getDebugSimpleTemplateNames();
-  
   if (!CGM.getCodeGenOpts().hasReducedDebugInfo())
     TemplateNamesKind = codegenoptions::DebugTemplateNamesKind::Full;
 
   Optional<TemplateArgs> Args;
 
   bool IsOperatorOverload = false; // isa<CXXConversionDecl>(ND);
   if (auto *RD = dyn_cast<CXXRecordDecl>(ND)) {
     Args = GetTemplateArgs(RD);
void CGDebugInfo::EmitGlobalAlias(const llvm::GlobalValue *GV,
 
   llvm::DIImportedEntity *ImportDI = DBuilder.createImportedDeclaration(
       DContext, DI, getOrCreateFile(Loc), getLineNumber(Loc), D->getName());
 
   // Record this DIE in the cache for nested declaration reference.
   ImportedDeclCache[GD.getCanonicalDecl().getDecl()].reset(ImportDI);
 }
 
+void CGDebugInfo::AddStringLiteralDebugInfo(llvm::GlobalVariable *GV,
+                                            StringRef Name,
+                                            const StringLiteral *S) {
+  SourceLocation Loc = S->getStrTokenLoc(0);
+  PresumedLoc PLoc = CGM.getContext().getSourceManager().getPresumedLoc(Loc);
+  if (!PLoc.isValid())
+    return;
+
+  llvm::DIFile *File = getOrCreateFile(Loc);
+  llvm::DIGlobalVariableExpression *Debug =
+      DBuilder.createGlobalVariableExpression(
+          nullptr, StringRef(), StringRef(), getOrCreateFile(Loc),
+          getLineNumber(Loc), getOrCreateType(S->getType(), File), true);
+  GV->addDebugInfo(Debug);
+}
+
 llvm::DIScope *CGDebugInfo::getCurrentContextDescriptor(const Decl *D) {
   if (!LexicalBlockStack.empty())
     return LexicalBlockStack.back();
   llvm::DIScope *Mod = getParentModuleOrNull(D);
   return getContextDescriptor(D, Mod ? Mod : TheCU);
 }
 
 void CGDebugInfo::EmitUsingDirective(const UsingDirectiveDecl &UD) {

clang/lib/CodeGen/CodeGenModule.cpp

if (getCXXABI().getMangleContext().shouldMangleStringLiteral(S) &&
     LT = llvm::GlobalValue::LinkOnceODRLinkage;
     GlobalVariableName = MangledNameBuffer;
   } else {
     LT = llvm::GlobalValue::PrivateLinkage;
     GlobalVariableName = Name;
   }
 
   auto GV = GenerateStringLiteral(C, LT, *this, GlobalVariableName, Alignment);
+
+  CGDebugInfo *DI = getModuleDebugInfo();
+  if (DI && getCodeGenOpts().hasReducedDebugInfo())
+    DI->AddStringLiteralDebugInfo(GV, GlobalVariableName, S);
+
   if (Entry)
     *Entry = GV;
 
   SanitizerMD->reportGlobalToASan(GV, S->getStrTokenLoc(0), "<string literal>",
                                   QualType());
 
   return ConstantAddress(castStringLiteralToDefaultAddressSpace(*this, GV),
                          GV->getValueType(), Alignment);

clang/test/CodeGen/debug-info-variables.c

+// RUN: %clang_cc1 %s -debug-info-kind=standalone -S -emit-llvm -o - | FileCheck %s
+
+// CHECK: DIGlobalVariable(name: "global"
+int global = 42;
+
+// CHECK: DIGlobalVariable({{.*}}line: [[@LINE+2]]
+const char* s() {
+  return "1234567890";
+}
+
+// CHECK: DILocalVariable(name: "p"
+// CHECK: DILocalVariable(name: "q"
+// CHECK: DILocalVariable(name: "r"
+int sum(int p, int q) {
+  int r = p + q;
+  return r;
+}

clang/test/VFS/external-names.c

 
 // RUN: %clang_cc1 -I %t -ivfsoverlay %t.yaml -fsyntax-only %s 2>&1 | FileCheck -check-prefix=CHECK-DIAG %s
 // CHECK-DIAG-NOT: Inputs
 
 ////
 // Debug info
 
 // RUN: %clang_cc1 -I %t -ivfsoverlay %t.external.yaml -triple %itanium_abi_triple -debug-info-kind=limited -emit-llvm %s -o - | FileCheck -check-prefix=CHECK-DEBUG-EXTERNAL %s
-// CHECK-DEBUG-EXTERNAL: !DISubprogram({{.*}}file: ![[Num:[0-9]+]]
-// CHECK-DEBUG-EXTERNAL: ![[Num]] = !DIFile(filename: "{{[^"]*}}Inputs{{..?}}external-names.h"
+// CHECK-DEBUG-EXTERNAL: ![[Num:[0-9]+]] = !DIFile(filename: "{{[^"]*}}Inputs{{..?}}external-names.h"
+// CHECK-DEBUG-EXTERNAL: !DISubprogram({{.*}}file: ![[Num]]
 
 // RUN: %clang_cc1 -I %t -ivfsoverlay %t.yaml -triple %itanium_abi_triple -debug-info-kind=limited -emit-llvm %s -o - | FileCheck -check-prefix=CHECK-DEBUG %s
 // CHECK-DEBUG-NOT: Inputs
 
 ////
 // Dependency file
 
 // RUN: %clang_cc1 -D REINCLUDE -I %t -ivfsoverlay %t.external.yaml -Eonly %s -MTfoo -dependency-file %t.external.dep
 // RUN: echo "EOF" >> %t.external.dep
 // RUN: cat %t.external.dep | FileCheck --check-prefix=CHECK-DEP-EXTERNAL %s
 // CHECK-DEP-EXTERNAL: Inputs{{..?}}external-names.h
 // CHECK-DEP-EXTERNAL-NEXT: EOF
 
 // RUN: %clang_cc1 -D REINCLUDE -I %t -ivfsoverlay %t.yaml -Eonly %s -MTfoo -dependency-file %t.dep
 // RUN: cat %t.dep | FileCheck --check-prefix=CHECK-DEP %s
 // CHECK-DEP-NOT: Inputs

llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp

if (auto *SDMDecl = GV->getStaticDataMemberDeclaration()) {
     addDIEEntry(*VariableDIE, dwarf::DW_AT_specification, *VariableSpecDIE);
     // If the global variable's type is different from the one in the class
     // member type, assume that it's more specific and also emit it.
     if (GTy != SDMDecl->getBaseType())
       addType(*VariableDIE, GTy);
   } else {
     DeclContext = GV->getScope();
     // Add name and type.
+    StringRef DisplayName = GV->getDisplayName();
+    if (!DisplayName.empty())
       addString(*VariableDIE, dwarf::DW_AT_name, GV->getDisplayName());
     if (GTy)
       addType(*VariableDIE, GTy);
 
     // Add scoping info.
     if (!GV->isLocalToUnit())
       addFlag(*VariableDIE, dwarf::DW_AT_external);
 
     // Add line number info.