[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

249

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

249

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

249

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

1282–1284

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)

1285–1286

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

750

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

751

maybe DWARFDie supports range-based for loop now?

786–788

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.

791–793

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

249

changed, thanks for clarifying before

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

751

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

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

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1044–1046

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).

1047

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

1044–1046

ack, thanks for the colour

1047

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

47

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

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

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

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

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

Sure, done.

[dblaikie]

Seems OK

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

1040–1053

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

778–779

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)

794–797

Maybe swap this around to reduce indentation/conditionality:

[hctim]

David's comments.

llvm/include/llvm/DebugInfo/DIContext.h

public:
   void resize(unsigned i) { Frames.resize(i); }
 };
 
 /// Container for description of a global variable.
 struct DIGlobal {
   std::string Name;
   uint64_t Start = 0;
   uint64_t Size = 0;
+  std::string DeclFile;
+  uint64_t DeclLine = 0;
 
   DIGlobal() : Name(DILineInfo::BadString) {}
 };
 
 struct DILocal {
   std::string FunctionName;
   std::string Name;
   std::string DeclFile;
public:
   virtual bool verify(raw_ostream &OS, DIDumpOptions DumpOpts = {}) {
     // No verifier? Just say things went well.
     return true;
   }
 
   virtual DILineInfo getLineInfoForAddress(
       object::SectionedAddress Address,
       DILineInfoSpecifier Specifier = DILineInfoSpecifier()) = 0;
+  virtual DILineInfo
+  getLineInfoForDataAddress(object::SectionedAddress Address) = 0;
   virtual DILineInfoTable getLineInfoForAddressRange(
       object::SectionedAddress Address, uint64_t Size,
       DILineInfoSpecifier Specifier = DILineInfoSpecifier()) = 0;
   virtual DIInliningInfo getInliningInfoForAddress(
       object::SectionedAddress Address,
       DILineInfoSpecifier Specifier = DILineInfoSpecifier()) = 0;
 
   virtual std::vector<DILocal>

llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h

public:
   /// given address where applicable.
   /// TODO: change input parameter from "uint64_t Address"
   ///       into "SectionedAddress Address"
   DIEsForAddress getDIEsForAddress(uint64_t Address);
 
   DILineInfo getLineInfoForAddress(
       object::SectionedAddress Address,
       DILineInfoSpecifier Specifier = DILineInfoSpecifier()) override;
+  DILineInfo
+  getLineInfoForDataAddress(object::SectionedAddress Address) override;
   DILineInfoTable getLineInfoForAddressRange(
       object::SectionedAddress Address, uint64_t Size,
       DILineInfoSpecifier Specifier = DILineInfoSpecifier()) override;
   DIInliningInfo getInliningInfoForAddress(
       object::SectionedAddress Address,
       DILineInfoSpecifier Specifier = DILineInfoSpecifier()) override;
 
   std::vector<DILocal>

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

 //===- DWARFUnit.h ----------------------------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_DEBUGINFO_DWARF_DWARFUNIT_H
 #define LLVM_DEBUGINFO_DWARF_DWARFUNIT_H
 
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/BinaryFormat/Dwarf.h"
 #include "llvm/DebugInfo/DWARF/DWARFAddressRange.h"
 #include "llvm/DebugInfo/DWARF/DWARFDataExtractor.h"
 #include "llvm/DebugInfo/DWARF/DWARFDebugInfoEntry.h"
 #include "llvm/DebugInfo/DWARF/DWARFDie.h"
 #include "llvm/DebugInfo/DWARF/DWARFLocationExpression.h"
 #include "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"
 #include "llvm/Support/DataExtractor.h"
 #include <cassert>
 #include <cstddef>
 #include <cstdint>
 #include <map>
 #include <memory>
+#include <set>
 #include <utility>
 #include <vector>
 
 namespace llvm {
 
 class DWARFAbbreviationDeclarationSet;
 class DWARFContext;
 class DWARFDebugAbbrev;
class DWARFUnit {
   /// The compile unit debug information entry items.
   std::vector<DWARFDebugInfoEntry> DieArray;
 
   /// Map from range's start address to end address and corresponding DIE.
   /// IntervalMap does not support range removal, as a result, we use the
   /// std::map::upper_bound for address range lookup.
   std::map<uint64_t, std::pair<uint64_t, DWARFDie>> AddrDieMap;
 
+  /// Map from the location (interpreted DW_AT_location) of a DW_TAG_variable,
+  /// to the DIE.
+  DenseMap<uint64_t, DWARFDie> VariableDieMap;
+  DenseSet<uint64_t> RootsParsedForVariables;
+
   using die_iterator_range =
       iterator_range<std::vector<DWARFDebugInfoEntry>::iterator>;
 
   std::shared_ptr<DWARFUnit> DWO;
 
   uint32_t getDIEIndex(const DWARFDebugInfoEntry *Die) {
     auto First = DieArray.data();
     assert(Die >= First && Die < First + DieArray.size());
public:
 
   Optional<uint64_t> getAddrOffsetSectionBase() const {
     return AddrOffsetSectionBase;
   }
 
   /// Recursively update address to Die map.
   void updateAddressDieMap(DWARFDie Die);
 
+  /// Recursively update address to variable Die map.
+  void updateVariableDieMap(DWARFDie Die);
+
   void setRangesSection(const DWARFSection *RS, uint64_t Base) {
     RangeSection = RS;
     RangeSectionBase = Base;
   }
 
   uint64_t getLocSectionBase() const {
     return LocSectionBase;
   }
public:
   Expected<DWARFLocationExpressionsVector>
   findLoclistFromOffset(uint64_t Offset);
 
   /// Returns subprogram DIE with address range encompassing the provided
   /// address. The pointer is alive as long as parsed compile unit DIEs are not
   /// cleared.
   DWARFDie getSubroutineForAddress(uint64_t Address);
 
+  /// Returns variable DIE for the address provided. The pointer is alive as
+  /// long as parsed compile unit DIEs are not cleared.
+  DWARFDie getVariableForAddress(uint64_t Address);
+
   /// getInlinedChainForAddress - fetches inlined chain for a given address.
   /// Returns empty chain if there is no subprogram containing address. The
   /// chain is valid as long as parsed compile unit DIEs are not cleared.
   void getInlinedChainForAddress(uint64_t Address,
                                  SmallVectorImpl<DWARFDie> &InlinedChain);
 
   /// Return the DWARFUnitVector containing this unit.
   const DWARFUnitVector &getUnitVector() const { return UnitVector; }

llvm/include/llvm/DebugInfo/PDB/PDBContext.h

static bool classof(const DIContext *DICtx) {
       return DICtx->getKind() == CK_PDB;
     }
 
     void dump(raw_ostream &OS, DIDumpOptions DIDumpOpts) override;
 
     DILineInfo getLineInfoForAddress(
         object::SectionedAddress Address,
         DILineInfoSpecifier Specifier = DILineInfoSpecifier()) override;
+    DILineInfo
+    getLineInfoForDataAddress(object::SectionedAddress Address) override;
     DILineInfoTable getLineInfoForAddressRange(
         object::SectionedAddress Address, uint64_t Size,
         DILineInfoSpecifier Specifier = DILineInfoSpecifier()) override;
     DIInliningInfo getInliningInfoForAddress(
         object::SectionedAddress Address,
         DILineInfoSpecifier Specifier = DILineInfoSpecifier()) override;
 
     std::vector<DILocal>

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp

DWARFCompileUnit *DWARFContext::getCompileUnitForOffset(uint64_t Offset) {
   return dyn_cast_or_null<DWARFCompileUnit>(
       NormalUnits.getUnitForOffset(Offset));
 }
 
 DWARFCompileUnit *DWARFContext::getCompileUnitForAddress(uint64_t Address) {
   // First, get the offset of the compile unit.
   uint64_t CUOffset = getDebugAranges()->findAddress(Address);
   // Retrieve the compile unit.
-  return getCompileUnitForOffset(CUOffset);
+  DWARFCompileUnit *OffsetCU = getCompileUnitForOffset(CUOffset);
+  if (OffsetCU)
+    return OffsetCU;
+
+  // Unfortunately, debug_aranges by default don't inclue global variables. If
+  // we failed to find the CU using aranges, try and search for variables as
+  // well.
+  for (std::unique_ptr<DWARFUnit> &CU : compile_units()) {
+    if (DWARFDie Die = CU->getVariableForAddress(Address)) {
+      return static_cast<DWARFCompileUnit *>(CU.get());
+    }
+  }
+  return nullptr;
 }
 
 DWARFContext::DIEsForAddress DWARFContext::getDIEsForAddress(uint64_t Address) {
   DIEsForAddress Result;
 
   DWARFCompileUnit *CU = getCompileUnitForAddress(Address);
   if (!CU)
     return Result;
 
DWARFContext::getLocalsForAddress(object::SectionedAddress Address) {
   if (Subprogram.isValid())
     addLocalsForDie(CU, Subprogram, Subprogram, Result);
   return Result;
 }
 
 DILineInfo DWARFContext::getLineInfoForAddress(object::SectionedAddress Address,
                                                DILineInfoSpecifier Spec) {
   DILineInfo Result;
-
   DWARFCompileUnit *CU = getCompileUnitForAddress(Address.Address);
   if (!CU)
     return Result;
 
   getFunctionNameAndStartLineForAddress(
       CU, Address.Address, Spec.FNKind, Spec.FLIKind, Result.FunctionName,
       Result.StartFileName, Result.StartLine, Result.StartAddress);
   if (Spec.FLIKind != FileLineInfoKind::None) {
     if (const DWARFLineTable *LineTable = getLineTableForUnit(CU)) {
       LineTable->getFileLineInfoForAddress(
           {Address.Address, Address.SectionIndex}, CU->getCompilationDir(),
           Spec.FLIKind, Result);
     }
   }
+
+  return Result;
+}
+
+DILineInfo
+DWARFContext::getLineInfoForDataAddress(object::SectionedAddress Address) {
+  DILineInfo Result;
+  DWARFCompileUnit *CU = getCompileUnitForAddress(Address.Address);
+  if (!CU)
+    return Result;
+
+  if (DWARFDie Die = CU->getVariableForAddress(Address.Address)) {
+    Result.FileName = Die.getDeclFile(FileLineInfoKind::AbsoluteFilePath);
+    Result.Line = Die.getDeclLine();
+  }
+
   return Result;
 }
 
 DILineInfoTable DWARFContext::getLineInfoForAddressRange(
     object::SectionedAddress Address, uint64_t Size, DILineInfoSpecifier Spec) {
   DILineInfoTable Lines;
   DWARFCompileUnit *CU = getCompileUnitForAddress(Address.Address);
   if (!CU)

llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp

 #include "llvm/DebugInfo/DWARF/DWARFDebugRangeList.h"
 #include "llvm/DebugInfo/DWARF/DWARFDebugRnglists.h"
 #include "llvm/DebugInfo/DWARF/DWARFDie.h"
 #include "llvm/DebugInfo/DWARF/DWARFFormValue.h"
 #include "llvm/DebugInfo/DWARF/DWARFListTable.h"
 #include "llvm/DebugInfo/DWARF/DWARFObject.h"
 #include "llvm/DebugInfo/DWARF/DWARFSection.h"
 #include "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
+#include "llvm/Object/ObjectFile.h"
 #include "llvm/Support/DataExtractor.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/Path.h"
 #include <algorithm>
 #include <cassert>
 #include <cstddef>
 #include <cstdint>
 #include <utility>
if (R == AddrDieMap.begin())
     return DWARFDie();
   // upper_bound's previous item contains Address.
   --R;
   if (Address >= R->second.first)
     return DWARFDie();
   return R->second.second;
 }
 
+void DWARFUnit::updateVariableDieMap(DWARFDie Die) {
+  for (DWARFDie Child : Die) {
+    if (isType(Child.getTag()))
+      continue;
+    updateVariableDieMap(Child);
+  }
+
+  if (Die.getTag() != DW_TAG_variable)
+    return;
+
+  Expected<DWARFLocationExpressionsVector> Locations =
+      Die.getLocations(DW_AT_location);
+  if (!Locations) {
+    // Missing DW_AT_location is fine here.
+    consumeError(Locations.takeError());
+    return;
+  }
+
+  for (const DWARFLocationExpression &Location : *Locations) {
+    DataExtractor Data(Location.Expr, /*IsLittleEndian=*/true, 8);
+    uint64_t DataOffset = 0;
+    uint8_t Operation = Data.getU8(&DataOffset);
+    if (Operation == dwarf::DW_OP_addr) {
+      uint64_t Pointer = Data.getAddress(&DataOffset);
+      VariableDieMap[Pointer] = Die;
+      return;
+    }
+    if (Operation == dwarf::DW_OP_addrx) {
+      uint64_t DebugAddrOffset = Data.getULEB128(&DataOffset);
+      Optional<object::SectionedAddress> Pointer =
+          getAddrOffsetSectionItem(DebugAddrOffset);
+      if (Pointer)
+        VariableDieMap[Pointer->Address] = Die;
+    }
+  }
+}
+
+DWARFDie DWARFUnit::getVariableForAddress(uint64_t Address) {
+  extractDIEsIfNeeded(false);
+
+  auto RootDie = getUnitDIE();
+
+  auto RootLookup = RootsParsedForVariables.insert(RootDie.getOffset());
+  if (RootLookup.second)
+    updateVariableDieMap(RootDie);
+
+  auto it = VariableDieMap.find(Address);
+  if (it == VariableDieMap.end())
+    return DWARFDie();
+  return it->second;
+}
+
 void
 DWARFUnit::getInlinedChainForAddress(uint64_t Address,
                                      SmallVectorImpl<DWARFDie> &InlinedChain) {
   assert(InlinedChain.empty());
   // Try to look for subprogram DIEs in the DWO file.
   parseDWO();
   // First, find the subroutine that contains the given address (the leaf
   // of inlined chain).

llvm/lib/DebugInfo/PDB/PDBContext.cpp

DILineInfo PDBContext::getLineInfoForAddress(object::SectionedAddress Address,
   if (SourceFile &&
       Specifier.FLIKind != DILineInfoSpecifier::FileLineInfoKind::None)
     Result.FileName = SourceFile->getFileName();
   Result.Column = LineInfo->getColumnNumber();
   Result.Line = LineInfo->getLineNumber();
   return Result;
 }
 
+DILineInfo
+PDBContext::getLineInfoForDataAddress(object::SectionedAddress Address) {
+  // Unimplemented.
+  return DILineInfo();
+}
+
 DILineInfoTable
 PDBContext::getLineInfoForAddressRange(object::SectionedAddress Address,
                                        uint64_t Size,
                                        DILineInfoSpecifier Specifier) {
   if (Size == 0)
     return DILineInfoTable();
 
   DILineInfoTable Table;

llvm/lib/DebugInfo/Symbolize/DIPrinter.cpp

 
 void PlainPrinterBase::print(const Request &Request, const DIGlobal &Global) {
   printHeader(*Request.Address);
   StringRef Name = Global.Name;
   if (Name == DILineInfo::BadString)
     Name = DILineInfo::Addr2LineBadString;
   OS << Name << "\n";
   OS << Global.Start << " " << Global.Size << "\n";
+  if (Global.DeclFile.empty())
+    OS << "??:?\n";
+  else
+    OS << Global.DeclFile << ":" << Global.DeclLine << "\n";
   printFooter();
 }
 
 void PlainPrinterBase::print(const Request &Request,
                              const std::vector<DILocal> &Locals) {
   printHeader(*Request.Address);
   if (Locals.empty())
     OS << DILineInfo::Addr2LineBadString << '\n';

llvm/lib/DebugInfo/Symbolize/SymbolizableObjectFile.cpp

 }
 
 DIGlobal SymbolizableObjectFile::symbolizeData(
     object::SectionedAddress ModuleOffset) const {
   DIGlobal Res;
   std::string FileName;
   getNameFromSymbolTable(ModuleOffset.Address, Res.Name, Res.Start, Res.Size,
                          FileName);
+  Res.DeclFile = FileName;
+
+  // Try and get a better filename:lineno pair from the debuginfo, if present.
+  DILineInfo DL = DebugInfoContext->getLineInfoForDataAddress(ModuleOffset);
+  if (DL.Line != 0) {
+    Res.DeclFile = DL.FileName;
+    Res.DeclLine = DL.Line;
+  }
   return Res;
 }
 
 std::vector<DILocal> SymbolizableObjectFile::symbolizeFrame(
     object::SectionedAddress ModuleOffset) const {
   if (ModuleOffset.SectionIndex == object::SectionedAddress::UndefSection)
     ModuleOffset.SectionIndex =
         getModuleSectionIndexForAddress(ModuleOffset.Address);

llvm/test/DebugInfo/Symbolize/ELF/data-command-symtab.yaml

 ## Function and data symbols have different addresses so internally we treat
 ## STT_NOTYPE/STT_FUNC/STT_DATA/etc the same. The DATA command may get a function
 ## as result. For regular applications, the input addresses are guaranteed to be
 ## related to data symbols.
 # RUN: yaml2obj %s -o %t
 # RUN: llvm-symbolizer --obj=%t 'DATA 0x1000' 'DATA 0x2000' 'DATA 0x2002' | FileCheck %s
 
 # CHECK:       func
 # CHECK-NEXT:  4096 1
+# CHECK-NEXT:  ??:?
 # CHECK-EMPTY:
 # CHECK-NEXT:  data
 # CHECK-NEXT:  8192 2
+# CHECK-NEXT:  ??:?
 # CHECK-EMPTY:
 # CHECK-NEXT:  notype
 # CHECK-NEXT:  8194 3
+# CHECK-NEXT:  ??:?
 # CHECK-EMPTY:
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_EXEC
   Machine: EM_X86_64

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

+## Show that when "DATA" is used with an address, it forces the found location
+## to be symbolized as data, including the source information.
+
+# RUN: yaml2obj %s -o %t.so
+
+# RUN: llvm-symbolizer "DATA 0x38a4" "DATA 0x3868" "DATA 0x38a0" \
+# RUN:   --obj=%t.so | FileCheck %s
+
+# CHECK:      bss_global
+# CHECK-NEXT: {{[0-9]+}} 4
+# CHECK-NEXT: /tmp/file.c:1
+# CHECK-EMPTY:
+# CHECK-NEXT: data_global
+# CHECK-NEXT: {{[0-9]+}} 4
+# CHECK-NEXT: /tmp/file.c:2
+# CHECK-EMPTY:
+# CHECK-NEXT: f.function_global
+# CHECK-NEXT: {{[0-9]+}} 4
+# CHECK-NEXT: /tmp/file.c:4
+# CHECK-EMPTY:
+
+################################################################################
+## File below was generated using:
+##   $ clang -g -fuse-ld=lld -shared /tmp/file.c -o out.so && obj2yaml out.so
+## ... with /tmp/file.c:
+##   1: int bss_global;
+##   2: int data_global = 2;
+##   3: void f() {
+##   4:   static int function_global;
+##   5: }
+##   6:
+## ... then, one can get the offsets using `nm`, like:
+##   $ nm out.so | grep bss_global
+##     00000000000038fc B bss_global
+##
+## Ideally, this would be tested by invoking clang directly on a C source file,
+## but unfortunately there's no way to do that for LLVM tests. The other option
+## is to compile IR to an objfile, but llvm-symbolizer doesn't understand that
+## two symbols can have the same address in different sections. In the code
+## above, for example, we'd have bss_global at .bss+0x0, and data_global at
+## .data+0x0, and so the symbolizer would only print one of them. Hence, we have
+## the ugly dso-to-yaml blob below.
+##
+## For now, constant strings don't have a debuginfo entry, and so can't be
+## symbolized correctly. In future (if D123534 gets merged), this can be updated
+## to include a check that llvm-symbolizer can also symbolize constant strings,
+## like `const char* string = "123456"` (and &"123456" should be symbolizable)
+## to the specific line. Then, you can find the address of the constant string
+## from the relocation:
+##   $ nm out.so | grep string
+##     00000000000038c0 D string
+##   $ llvm-objdump -R out.so | grep 38c0
+##     00000000000038c0 R_X86_64_RELATIVE *ABS*+0x4f8 # <-- 0x4f8
+################################################################################
+
+--- !ELF
+FileHeader:
+  Class:           ELFCLASS64
+  Data:            ELFDATA2LSB
+  Type:            ET_DYN
+  Machine:         EM_X86_64
+ProgramHeaders:
+  - Type:            PT_PHDR
+    Flags:           [ PF_R ]
+    VAddr:           0x40
+    Align:           0x8
+  - Type:            PT_LOAD
+    Flags:           [ PF_R ]
+    FirstSec:        .dynsym
+    LastSec:         .eh_frame
+    Align:           0x1000
+  - Type:            PT_LOAD
+    Flags:           [ PF_X, PF_R ]
+    FirstSec:        .text
+    LastSec:         .plt
+    VAddr:           0x1510
+    Align:           0x1000
+  - Type:            PT_LOAD
+    Flags:           [ PF_W, PF_R ]
+    FirstSec:        .ctors
+    LastSec:         .got
+    VAddr:           0x26D0
+    Align:           0x1000
+  - Type:            PT_LOAD
+    Flags:           [ PF_W, PF_R ]
+    FirstSec:        .data
+    LastSec:         .bss
+    VAddr:           0x3860
+    Align:           0x1000
+  - Type:            PT_DYNAMIC
+    Flags:           [ PF_W, PF_R ]
+    FirstSec:        .dynamic
+    LastSec:         .dynamic
+    VAddr:           0x26F0
+    Align:           0x8
+  - Type:            PT_GNU_RELRO
+    Flags:           [ PF_R ]
+    FirstSec:        .ctors
+    LastSec:         .got
+    VAddr:           0x26D0
+  - Type:            PT_GNU_EH_FRAME
+    Flags:           [ PF_R ]
+    FirstSec:        .eh_frame_hdr
+    LastSec:         .eh_frame_hdr
+    VAddr:           0x4B0
+    Align:           0x4
+  - Type:            PT_GNU_STACK
+    Flags:           [ PF_W, PF_R ]
+    Align:           0x0
+Sections:
+  - Name:            .dynsym
+    Type:            SHT_DYNSYM
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x238
+    Link:            .dynstr
+    AddressAlign:    0x8
+  - Name:            .gnu.version
+    Type:            SHT_GNU_versym
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x2F8
+    Link:            .dynsym
+    AddressAlign:    0x2
+    Entries:         [ 0, 1, 1, 1, 2, 1, 1, 1 ]
+  - Name:            .gnu.version_r
+    Type:            SHT_GNU_verneed
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x308
+    Link:            .dynstr
+    AddressAlign:    0x4
+    Dependencies:
+      - Version:         1
+        File:            libc.so.6
+        Entries:
+          - Name:            GLIBC_2.2.5
+            Hash:            157882997
+            Flags:           0
+            Other:           2
+  - Name:            .gnu.hash
+    Type:            SHT_GNU_HASH
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x328
+    Link:            .dynsym
+    AddressAlign:    0x8
+    Header:
+      SymNdx:          0x5
+      Shift2:          0x1A
+    BloomFilter:     [ 0x1800021000801 ]
+    HashBuckets:     [ 0x5 ]
+    HashValues:      [ 0x2B60A, 0x61F7372E, 0xC033991D ]
+  - Name:            .hash
+    Type:            SHT_HASH
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x350
+    Link:            .dynsym
+    AddressAlign:    0x4
+    Bucket:          [ 0, 0, 0, 0, 7, 4, 5, 1 ]
+    Chain:           [ 0, 0, 0, 2, 3, 0, 0, 6 ]
+  - Name:            .dynstr
+    Type:            SHT_STRTAB
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x398
+    AddressAlign:    0x1
+  - Name:            .rela.dyn
+    Type:            SHT_RELA
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x420
+    Link:            .dynsym
+    AddressAlign:    0x8
+    Relocations:
+      - Offset:          0x3860
+        Type:            R_X86_64_RELATIVE
+        Addend:          14432
+      - Offset:          0x2840
+        Symbol:          __gmon_start__
+        Type:            R_X86_64_GLOB_DAT
+      - Offset:          0x2848
+        Symbol:          _ITM_deregisterTMCloneTable
+        Type:            R_X86_64_GLOB_DAT
+      - Offset:          0x2850
+        Symbol:          _ITM_registerTMCloneTable
+        Type:            R_X86_64_GLOB_DAT
+      - Offset:          0x2858
+        Symbol:          __cxa_finalize
+        Type:            R_X86_64_GLOB_DAT
+  - Name:            .rela.plt
+    Type:            SHT_RELA
+    Flags:           [ SHF_ALLOC, SHF_INFO_LINK ]
+    Address:         0x498
+    Link:            .dynsym
+    AddressAlign:    0x8
+    Info:            .got.plt
+    Relocations:
+      - Offset:          0x3888
+        Symbol:          __cxa_finalize
+        Type:            R_X86_64_JUMP_SLOT
+  - Name:            .eh_frame_hdr
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x4B0
+    AddressAlign:    0x4
+    Content:         011B033B14000000010000007011000030000000
+  - Name:            .eh_frame
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC ]
+    Address:         0x4C8
+    AddressAlign:    0x8
+    Content:         1400000000000000017A5200017810011B0C0708900100001C0000001C000000381100000600000000410E108602430D06410C070800000000000000
+  - Name:            .text
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
+    Address:         0x1510
+    AddressAlign:    0x10
+    Content:         488D3D59230000488D05522300004839F87415488B051E1300004885C07409FFE00F1F8000000000C30F1F8000000000488D3D29230000488D35222300004829FE4889F048C1EE3F48C1F8034801C648D1FE7414488B05E51200004885C07408FFE0660F1F440000C30F1F8000000000F30F1EFA803D0523000000757B5548833DC2120000004889E5415453740C488B3DBB220000E816010000488D052F110000488D1D301100004829C34989C4488B05D322000048C1FB034883EB014839D87321660F1F4400004883C001488905B522000041FF14C4488B05AA2200004839D872E5E818FFFFFF5B415CC6058E220000015DC30F1F4000C30F1F8000000000F30F1EFAE927FFFFFFCCCCCCCCCCCCCC554889E55DC3CCCCCCCCCCCCCCCCCCCCF30F1EFA488B05951000004883F8FF742F554889E553488D1D831000004883EC080F1F8000000000FFD0488B43F84883EB084883F8FF75F0488B5DF8C9C36690C3
+  - Name:            .init
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
+    Address:         0x1674
+    AddressAlign:    0x4
+    Content:         4883EC08488B05C11100004885C07402FFD0E885FFFFFFE8A0FFFFFF4883C408C3
+  - Name:            .fini
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
+    Address:         0x1698
+    AddressAlign:    0x4
+    Content:         4883EC08E8DFFEFFFF4883C408C3
+  - Name:            .plt
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_ALLOC, SHF_EXECINSTR ]
+    Address:         0x16B0
+    AddressAlign:    0x10
+    Content:         FF35C2210000FF25C42100000F1F4000FF25C22100006800000000E9E0FFFFFF
+  - Name:            .ctors
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x26D0
+    AddressAlign:    0x8
+    Content:         FFFFFFFFFFFFFFFF0000000000000000
+  - Name:            .dtors
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x26E0
+    AddressAlign:    0x8
+    Content:         FFFFFFFFFFFFFFFF0000000000000000
+  - Name:            .dynamic
+    Type:            SHT_DYNAMIC
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x26F0
+    Link:            .dynstr
+    AddressAlign:    0x8
+    Entries:
+      - Tag:             DT_NEEDED
+        Value:           0x6E
+      - Tag:             DT_RELA
+        Value:           0x420
+      - Tag:             DT_RELASZ
+        Value:           0x78
+      - Tag:             DT_RELAENT
+        Value:           0x18
+      - Tag:             DT_RELACOUNT
+        Value:           0x1
+      - Tag:             DT_JMPREL
+        Value:           0x498
+      - Tag:             DT_PLTRELSZ
+        Value:           0x18
+      - Tag:             DT_PLTGOT
+        Value:           0x3870
+      - Tag:             DT_PLTREL
+        Value:           0x7
+      - Tag:             DT_SYMTAB
+        Value:           0x238
+      - Tag:             DT_SYMENT
+        Value:           0x18
+      - Tag:             DT_STRTAB
+        Value:           0x398
+      - Tag:             DT_STRSZ
+        Value:           0x84
+      - Tag:             DT_GNU_HASH
+        Value:           0x328
+      - Tag:             DT_HASH
+        Value:           0x350
+      - Tag:             DT_INIT
+        Value:           0x1674
+      - Tag:             DT_FINI
+        Value:           0x1698
+      - Tag:             DT_VERSYM
+        Value:           0x2F8
+      - Tag:             DT_VERNEED
+        Value:           0x308
+      - Tag:             DT_VERNEEDNUM
+        Value:           0x1
+      - Tag:             DT_NULL
+        Value:           0x0
+  - Name:            .got
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x2840
+    AddressAlign:    0x8
+    Content:         '0000000000000000000000000000000000000000000000000000000000000000'
+  - Name:            .data
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x3860
+    AddressAlign:    0x8
+    Content:         '000000000000000002000000'
+  - Name:            .tm_clone_table
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x3870
+    AddressAlign:    0x8
+  - Name:            .got.plt
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x3870
+    AddressAlign:    0x8
+    Content:         F02600000000000000000000000000000000000000000000C616000000000000
+  - Name:            .bss
+    Type:            SHT_NOBITS
+    Flags:           [ SHF_WRITE, SHF_ALLOC ]
+    Address:         0x3890
+    AddressAlign:    0x8
+    Size:            0x18
+  - Name:            .comment
+    Type:            SHT_PROGBITS
+    Flags:           [ SHF_MERGE, SHF_STRINGS ]
+    AddressAlign:    0x1
+    EntSize:         0x1
+    Content:         4C696E6B65723A204C4C442031342E302E30004743433A202844656269616E2031312E322E302D3136292031312E322E300000636C616E672076657273696F6E2031342E302E30202868747470733A2F2F6769746875622E636F6D2F6C6C766D2F6C6C766D2D70726F6A6563742E67697420353335376139386338323361353236323831346532363964623236356235643865316632633466322900
+  - Name:            .debug_abbrev
+    Type:            SHT_PROGBITS
+    AddressAlign:    0x1
+    Content:         011101250E1305030E10171B0E110112060000023400030E49133F193A0B3B0B02180000032400030E3E0B0B0B0000042E01110112064018030E3A0B3B0B3F190000053400030E49133A0B3B0B0218000000
+  - Name:            .debug_info
+    Type:            SHT_PROGBITS
+    AddressAlign:    0x1
+    Content:         8300000004000000000008012E0000000C00020000000000000029000000201600000000000006000000020E0000003F000000010209036838000000000000031A000000050404201600000000000006000000015600000000010305970000003F00000001040903A03800000000000000021E0000003F00000001010903A43800000000000000
+  - Name:            .debug_line
+    Type:            SHT_PROGBITS
+    AddressAlign:    0x1
+    Content:         3900000004001E000000010101FB0E0D0001010101000000010000010066696C652E63000000000000090220160000000000001405010A4C0202000101
+Symbols:
+  - Name:            crtstuff.c
+    Type:            STT_FILE
+    Index:           SHN_ABS
+  - Name:            __CTOR_LIST__
+    Type:            STT_OBJECT
+    Section:         .ctors
+    Value:           0x26D0
+  - Name:            __DTOR_LIST__
+    Type:            STT_OBJECT
+    Section:         .dtors
+    Value:           0x26E0
+  - Name:            __TMC_LIST__
+    Type:            STT_OBJECT
+    Section:         .tm_clone_table
+    Value:           0x3870
+  - Name:            deregister_tm_clones
+    Type:            STT_FUNC
+    Section:         .text
+    Value:           0x1510
+  - Name:            register_tm_clones
+    Type:            STT_FUNC
+    Section:         .text
+    Value:           0x1540
+  - Name:            __do_global_dtors_aux
+    Type:            STT_FUNC
+    Section:         .text
+    Value:           0x1580
+  - Name:            completed.1
+    Type:            STT_OBJECT
+    Section:         .bss
+    Value:           0x3890
+    Size:            0x1
+  - Name:            dtor_idx.0
+    Type:            STT_OBJECT
+    Section:         .bss
+    Value:           0x3898
+    Size:            0x8
+  - Name:            frame_dummy
+    Type:            STT_FUNC
+    Section:         .text
+    Value:           0x1610
+  - Name:            __dso_handle
+    Type:            STT_OBJECT
+    Section:         .data
+    Value:           0x3860
+    Other:           [ STV_HIDDEN ]
+  - Name:            file.c
+    Type:            STT_FILE
+    Index:           SHN_ABS
+  - Name:            f.function_global
+    Type:            STT_OBJECT
+    Section:         .bss
+    Value:           0x38A0
+    Size:            0x4
+  - Name:            'crtstuff.c (1)'
+    Type:            STT_FILE
+    Index:           SHN_ABS
+  - Name:            __CTOR_END__
+    Type:            STT_OBJECT
+    Section:         .ctors
+    Value:           0x26D8
+  - Name:            __FRAME_END__
+    Type:            STT_OBJECT
+    Section:         .eh_frame
+    Value:           0x4C8
+  - Name:            __do_global_ctors_aux
+    Type:            STT_FUNC
+    Section:         .text
+    Value:           0x1630
+  - Name:            __TMC_END__
+    Type:            STT_OBJECT
+    Section:         .tm_clone_table
+    Value:           0x3870
+    Other:           [ STV_HIDDEN ]
+  - Name:            __DTOR_END__
+    Type:            STT_OBJECT
+    Section:         .dtors
+    Value:           0x26E8
+    Other:           [ STV_HIDDEN ]
+  - Name:            _init
+    Type:            STT_FUNC
+    Section:         .init
+    Value:           0x1674
+    Other:           [ STV_HIDDEN ]
+  - Name:            _fini
+    Type:            STT_FUNC
+    Section:         .fini
+    Value:           0x1698
+    Other:           [ STV_HIDDEN ]
+  - Name:            _GLOBAL_OFFSET_TABLE_
+    Section:         .got.plt
+    Value:           0x3870
+    Other:           [ STV_HIDDEN ]
+  - Name:            _DYNAMIC
+    Section:         .dynamic
+    Value:           0x26F0
+    Other:           [ STV_HIDDEN ]
+  - Name:            __gmon_start__
+    Binding:         STB_WEAK
+  - Name:            _ITM_deregisterTMCloneTable
+    Binding:         STB_WEAK
+  - Name:            _ITM_registerTMCloneTable
+    Binding:         STB_WEAK
+  - Name:            __cxa_finalize
+    Type:            STT_FUNC
+    Binding:         STB_WEAK
+  - Name:            f
+    Type:            STT_FUNC
+    Section:         .text
+    Binding:         STB_GLOBAL
+    Value:           0x1620
+    Size:            0x6
+  - Name:            data_global
+    Type:            STT_OBJECT
+    Section:         .data
+    Binding:         STB_GLOBAL
+    Value:           0x3868
+    Size:            0x4
+  - Name:            bss_global
+    Type:            STT_OBJECT
+    Section:         .bss
+    Binding:         STB_GLOBAL
+    Value:           0x38A4
+    Size:            0x4
+DynamicSymbols:
+  - Name:            __gmon_start__
+    Binding:         STB_WEAK
+  - Name:            _ITM_deregisterTMCloneTable
+    Binding:         STB_WEAK
+  - Name:            _ITM_registerTMCloneTable
+    Binding:         STB_WEAK
+  - Name:            __cxa_finalize
+    Type:            STT_FUNC
+    Binding:         STB_WEAK
+  - Name:            f
+    Type:            STT_FUNC
+    Section:         .text
+    Binding:         STB_GLOBAL
+    Value:           0x1620
+    Size:            0x6
+  - Name:            data_global
+    Type:            STT_OBJECT
+    Section:         .data
+    Binding:         STB_GLOBAL
+    Value:           0x3868
+    Size:            0x4
+  - Name:            bss_global
+    Type:            STT_OBJECT
+    Section:         .bss
+    Binding:         STB_GLOBAL
+    Value:           0x38A4
+    Size:            0x4
+DWARF:
+  debug_str:
+    - f
+    - '/tmp/file.c'
+    - data_global
+    - int
+    - bss_global
+    - '/tmp'
+    - 'clang version 14.0.0 (https://github.com/llvm/llvm-project.git 5357a98c823a5262814e269db265b5d8e1f2c4f2)'
+    - function_global
+...

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

 ## Show that when "DATA" is used with an address, it forces the found location
 ## to be symbolized as data.
 # REQUIRES: x86-registered-target
 # RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
 # RUN: llvm-symbolizer "DATA 0x2" "DATA 0x8" --obj=%t.o | \
 # RUN:   FileCheck %s -DFILE=%s --implicit-check-not={{.}}
 
 # CHECK:      d1
 # CHECK-NEXT: 0 8
+# CHECK-NEXT: ??:?
 # CHECK-EMPTY:
 # CHECK-NEXT: d2
 # CHECK-NEXT: 8 4
+# CHECK-NEXT: ??:?
+# CHECK-EMPTY:
 
 d1:
     .quad 0x1122334455667788
     .size d1, 8
 
 d2:
     .long 0x99aabbcc
     .size d2, 4