DebugInfo: Use base address selection entries for debug_loc

[dblaikie]

Summary

Unify the range and loc emission (for both DWARFv4 and DWARFv5 style lists) and take advantage of that unification to use strategic base addresses for loclists.

Needs more testing, but llvm-dwarfdump doesn't currently support LLE_base_addressx, for instance. But Pavel's looking at some changes there, so I'm holding off in case his work addresses it, or at least I can work on it afterwards so as not to conflict if I tried to do so now.

Anyone know whether they have consumers (LLDB, the Sony debugger) that would need to be updated for either the v4 changes (use of base address specifiers in classic debug_loc lists) or v5 (base_addressx, etc, etc)? GDB can't cope with the DWARFv5 stuff, but seems fine with the v4 version.

[labath]

LLDB seems to have support for base address selection in v4 debug_loc. It does not have support for v5 LLE_base_address(x) stuff, but the whole of v5 location list support is kind of wonky, which also is why I am looking at getting it to use the llvm version of the parser.

As for llvm-dwarfdump, feel free to add new encodings there. My plan is to add support for all LLE encodings, but since I also need to figure out a way to refactor all of that stuff, it may take a while before I get to that. Having one or two new encodings appear in the mean time should only be a minor nuisance.

[probinson]

Anyone know whether they have consumers (LLDB, the Sony debugger) that would need to be updated for either the v4 changes (use of base address specifiers in classic debug_loc lists) or v5 (base_addressx, etc, etc)?

I'll ask re Sony debugger. I have no direct visibility to that code.

[probinson]

BTW the BinaryFormat part LGTM and can go in on its own if you like. Should have been done that way in the first place.

[probinson]

For some reason a previous comment caused it to set Accept, and the only way I know to undo it is to set Request Changes. Sorry about that.

[probinson]

I'll ask re Sony debugger. I have no direct visibility to that code.

My debugger guys say they have code to handle it and some hand-coded tests, so they are cautiously optimistic that nothing bad will happen.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

2328 ↗

(On Diff #223716)

Would it be more readable this way?

if (!UseDwarf5) {
  Base = NewBase;
  BaseIsSet = true;
  Asm-OutStreamer->EmitIntValue(-1, Size);
  // etc
} else if (NewBase != Begin || P.second.size() > 1) {
  Base = NewBase;
  BaseIsSet = true;
  Asm->OutStreamer->AddComment(StringifyEnum(BaseAddressx);
  // etc
}

As there are only 2 lines in common. (My eye caught if (!UseDwarf5 and two lines later if (UseDwarf5) and did a double-take.)

[dblaikie]

In D68620#1699420, @labath wrote:

LLDB seems to have support for base address selection in v4 debug_loc. It does not have support for v5 LLE_base_address(x) stuff, but the whole of v5 location list support is kind of wonky, which also is why I am looking at getting it to use the llvm version of the parser.

Yeah, that sort of summarizes GDB's support too.

As for llvm-dwarfdump, feel free to add new encodings there. My plan is to add support for all LLE encodings, but since I also need to figure out a way to refactor all of that stuff, it may take a while before I get to that. Having one or two new encodings appear in the mean time should only be a minor nuisance.

Had to take a few goes at this to see if there was a good mid-point of refactoring & think I found one that coalesces some of the codepaths for verbose, non-verbose, and inline dumping - insofar as seemed reasonable, I tried to make things more similar to debug_rnglists (in several cases just at least making the code look similar, even though it's not shared yet).

lib/CodeGen/AsmPrinter/DwarfDebug.cpp

2328 ↗

(On Diff #223716)

Sure, looks good to me! I know this whole function's got several cases to think about & is a bit unwieldy.

[stella.stamenova]

I haven't fully debugged this, but it looks like this change caused a failure on the Windows LLDB bot. There was already another failure, so you probably didn't get an email:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9772

The Buildbot is still failing because of this test: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9884/steps/test/logs/stdio

When running the test locally, the output is:

(lldb) file E:\_work\22\b\tools\lldb\lldb-test-build.noindex\lang\c\local_variables\TestLocalVariables.test_c_local_variables_dwarf\a.out
Current executable set to 'E:\_work\22\b\tools\lldb\lldb-test-build.noindex\lang\c\local_variables\TestLocalVariables.test_c_local_variables_dwarf\a.out' (x86_64).
(lldb) br s -f main.c -l 13
Breakpoint 1: where = a.out`foo + 9 at main.c:13:3, address = 0x0000000140001029
(lldb) r
Process 43368 launched: 'E:\_work\22\b\tools\lldb\lldb-test-build.noindex\lang\c\local_variables\TestLocalVariables.test_c_local_variables_dwarf\a.out' (x86_64)
Process 43368 stopped
* thread #1, stop reason = breakpoint 1.1
    frame #0: 0x00007ff6a0141029 a.out`foo(j=<unavailable>) at main.c:13:3
   10     unsigned i = j;
   11     bar(i);
   12     i = 10;
-> 13     bar(i); // Set break point at this line.
   14   }
   15
   16   int main(int argc, char** argv)
(lldb) thread list
Process 43368 stopped
* thread #1: tid = 0x9a78, 0x00007ff6a0141029 a.out`foo(j=<unavailable>) at main.c:13:3, stop reason = breakpoint 1.1
(lldb) breakpoint list -f
Current breakpoints:
1: file = 'main.c', line = 13, exact_match = 0, locations = 1, resolved = 1, hit count = 1
  1.1: where = a.out`foo + 9 at main.c:13:3, address = 0x00007ff6a0141029, resolved, hit count = 1

(lldb) frame variable i
(unsigned int) i = <variable not available>

[labath]

In D68620#1709851, @stella.stamenova wrote:

I haven't fully debugged this, but it looks like this change caused a failure on the Windows LLDB bot. There was already another failure, so you probably didn't get an email:

http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9772

BTW, there were some failures on linux after this patch too, caused by lldb's incomplete support for base address selection entries. r374769 was enough to fix the failures I was seeing on linux, with the location parsing being as scattered as it is, it is possible I did not catch all cases.

[rupprecht]

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

[nickdesaulniers]

In D68620#1729184, @rupprecht wrote:

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

Yes; we're observing a 2.8% increase for non-LTO, 8.3% increase for LTO in Linux kernel image size when CONFIG_DEBUG_INFO is set to emit debug sections (DWARF4). b/154242577

Our LTO builds were also slowed down 4.2% by this.

@dblaikie was there any follow up to this?

[dblaikie]

In D68620#1995134, @nickdesaulniers wrote:

In D68620#1729184, @rupprecht wrote:

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

Yes; we're observing a 2.8% increase for non-LTO, 8.3% increase for LTO in Linux kernel image size when CONFIG_DEBUG_INFO is set to emit debug sections (DWARF4). b/154242577

Our LTO builds were also slowed down 4.2% by this.

@dblaikie was there any follow up to this?

No, there's not been any follow-up to this, it seems to have stuck fairly well in general. Happen to have a profile comparison for a representative compilation? (& any sense of the error bars on your measurements?)

Is executable size with debug info included a significant constraint for the Linux kernel image? (what's the scenario for that?) - if it is, perhaps linker debug info compression and/or Split DWARF, etc, might be helpful.

[dblaikie]

In D68620#1729184, @rupprecht wrote:

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

sorry I didn't see this (somehow ended up muting this thread) - which binary built with what flags? could you run bloaty or otherwise compare the objects before/after. I'd expect some growth in linked executable size of a non-split, optimized debug build, but that seems a bit more than I'd expect/seems to be observed elsewhere so far as I know.

[wolfgangp]

In D68620#1995191, @dblaikie wrote:

In D68620#1729184, @rupprecht wrote:

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

sorry I didn't see this (somehow ended up muting this thread) - which binary built with what flags? could you run bloaty or otherwise compare the objects before/after. I'd expect some growth in linked executable size of a non-split, optimized debug build, but that seems a bit more than I'd expect/seems to be observed elsewhere so far as I know.

FWIW, we're seeing about a 30-35% increase in the size of the .debug_loc sections across a variety of benchmarks (DWARF4, optimized build, non-split). Given that the majority of location lists seem to have 2 entries, and the base selection entry adds a third, this figure makes intuitive sense. The tradeoff is a reduced number of relocations against the .debug_loc sections, which does not seem to have all that much impact on link times.
Given that with DWARF v5 we can use the start_offset/end_offset LLE types with possibly small offset values, it seems that the tradeoff is more favorable towards base selection entries with DWARF5 than it is with DWARF4.

[dblaikie]

In D68620#2083696, @wolfgangp wrote:

In D68620#1995191, @dblaikie wrote:

In D68620#1729184, @rupprecht wrote:

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

sorry I didn't see this (somehow ended up muting this thread) - which binary built with what flags? could you run bloaty or otherwise compare the objects before/after. I'd expect some growth in linked executable size of a non-split, optimized debug build, but that seems a bit more than I'd expect/seems to be observed elsewhere so far as I know.

FWIW, we're seeing about a 30-35% increase in the size of the .debug_loc sections across a variety of benchmarks (DWARF4, optimized build, non-split). Given that the majority of location lists seem to have 2 entries, and the base selection entry adds a third, this figure makes intuitive sense. The tradeoff is a reduced number of relocations against the .debug_loc sections, which does not seem to have all that much impact on link times.
Given that with DWARF v5 we can use the start_offset/end_offset LLE types with possibly small offset values, it seems that the tradeoff is more favorable towards base selection entries with DWARF5 than it is with DWARF4.

Sorry I haven't given this more attention - but it is on my list (though I guess you've worked around it in some manner/downstream patch for now?) - but out of curiosity, does the change in 57d8acac64b87cb4286b00485fb2da7521fc091e help much? (I mean, it helps in general, so maybe you'd still want to disable the base address specifier use - even if it was offset by that change, because the change would still be a win in addition to disable the base address specifiers)

[dblaikie]

In D68620#2245573, @dblaikie wrote:

In D68620#2083696, @wolfgangp wrote:

In D68620#1995191, @dblaikie wrote:

In D68620#1729184, @rupprecht wrote:

It looks like this caused a very large increase in binary size (627M->686M). Is that expected/has anyone else observed this?

sorry I didn't see this (somehow ended up muting this thread) - which binary built with what flags? could you run bloaty or otherwise compare the objects before/after. I'd expect some growth in linked executable size of a non-split, optimized debug build, but that seems a bit more than I'd expect/seems to be observed elsewhere so far as I know.

FWIW, we're seeing about a 30-35% increase in the size of the .debug_loc sections across a variety of benchmarks (DWARF4, optimized build, non-split). Given that the majority of location lists seem to have 2 entries, and the base selection entry adds a third, this figure makes intuitive sense. The tradeoff is a reduced number of relocations against the .debug_loc sections, which does not seem to have all that much impact on link times.
Given that with DWARF v5 we can use the start_offset/end_offset LLE types with possibly small offset values, it seems that the tradeoff is more favorable towards base selection entries with DWARF5 than it is with DWARF4.

Sorry I haven't given this more attention - but it is on my list (though I guess you've worked around it in some manner/downstream patch for now?) - but out of curiosity, does the change in 57d8acac64b87cb4286b00485fb2da7521fc091e help much? (I mean, it helps in general, so maybe you'd still want to disable the base address specifier use - even if it was offset by that change, because the change would still be a win in addition to disable the base address specifiers)

@probinson - do you have any state here? Whether this is an ongoing issue, whether the improvements to avoid unnecessary debug_loc have reduced the overhead sufficiently, etc?

[probinson]

In D68620#2266531, @dblaikie wrote:

@probinson - do you have any state here? Whether this is an ongoing issue, whether the improvements to avoid unnecessary debug_loc have reduced the overhead sufficiently, etc?

@Orlando mentioned he was collecting some size data that would be relevant here, he'll post it when he's done. Basically .debug_loc sizes at various points.

But naively, pre-v5, base-address entries can only make lists longer, and for short lists the size cost is big while the reduction in relocations is small. I'd have to agree with @wolfgangp that the space-time tradeoff probably is not favorable for small lists, and maybe there should be some threshold. I know that's more complicated on the emission side, but it's not a trivial thing in the final object. Orlando showed me a preliminary chart where .debug_loc went from ~30% of all debug info in LLVM 5.0 to ~50% in LLVM 10.0, in one of our benchmarks.

[dblaikie]

In D68620#2271269, @probinson wrote:

In D68620#2266531, @dblaikie wrote:

@probinson - do you have any state here? Whether this is an ongoing issue, whether the improvements to avoid unnecessary debug_loc have reduced the overhead sufficiently, etc?

@Orlando mentioned he was collecting some size data that would be relevant here, he'll post it when he's done. Basically .debug_loc sizes at various points.

Awesome!

But naively, pre-v5, base-address entries can only make lists longer, and for short lists the size cost is big while the reduction in relocations is small.

Yep, at least on ELF, the relocation is 3 times the size (and uncompressible) than the address itself. So a debug_loc (or debug_range) entry with only a single entry is in favor of base address selection for object file size even without compression (2 addresses + 2 relocations (2 + 2 * 3 == 8), compared to 1 base address selection thing + 1 address + 1 relocation + 2 offsets == 7), but yes, that doubles the address size in the linked binary.

I'd have to agree with @wolfgangp that the space-time tradeoff probably is not favorable for small lists,

My hope/wonder is whether the reduction in unnecessary small (single entry that has scope identical to the enclosing scope: ie: the variable doesn't need a location list - it should use a direct location instead) entries might help make the tradeoff less problematic.

and maybe there should be some threshold. I know that's more complicated on the emission side, but it's not a trivial thing in the final object. Orlando showed me a preliminary chart where .debug_loc went from ~30% of all debug info in LLVM 5.0 to ~50% in LLVM 10.0, in one of our benchmarks.

Yeah - not sure exactly what basis to use to choose that threshold as it'll depend on how important object file size versus binary size is, whether you're using compression (whether only compressing DWARF in objects, executables, or both). But also making it a customizable number doesn't seem super helpful either. Open to ideas, for sure.

[Orlando]

@Orlando mentioned he was collecting some size data that would be relevant here, he'll post it when he's done. Basically .debug_loc sizes at various points.

Hi!

I've built a benchmark suite of 85 programs with "-O2 -g" with our downstream branch targeting X86 emitting DWARF v4.

This table provides a summary of the data. It shows the mean for some size data normalized as a percentage of the llvm-3 results for each benchmark.

For reference:
Largest binary built with llvm-3: 6010 kB
Smallest binary built with llvm-3: 79 kB

+------------------------------------------------------------------------------------------- +
| Mean binary size for benchmarks normalized as a percentage of llvm-3 builds                |
+---------------------------------+------------+------------------+-----------------+--------+
| llvm version                    | .debug_loc | other debug info | everything else | Total  |
+---------------------------------+------------+------------------+-----------------+--------+
| llvm-3                          | 13.7       | 33.2             | 53.1            | 100    |
| llvm-4                          | 12.7       | 33.8             | 53.8            | 100.3  |
| llvm-5                          | 13.4       | 35.6             | 54.6            | 103.7  |
| llvm-7                          | 18.4       | 35.6             | 54.0            | 108.0  |
| llvm-8                          | 17.5       | 37.1             | 54.5            | 109.1  |
| llvm-9                          | 19.7       | 37.2             | 54.6            | 111.5  |
| llvm-10 before dblaikie commit  | 19.8       | 37.4             | 54.9            | 112.1  |
| llvm-10 with dblaikie commit    | 25.6       | 37.4             | 54.9            | 117.9  |
| llvm-10                         | 25.8       | 37.5             | 54.8            | 118.1  |
| llvm-master before my commits   | 26.2       | 37.4             | 54.8            | 118.4  |
| llvm-master with my commits     | 18.4       | 35.5             | 55.3            | 109.3  |
+---------------------------------+------------+------------------+-----------------+--------+

Here's an image of that data in graph form: M3.

The llvm-6 entry has been omitted because the non debug-info size is a distracting outlier. The .debug_loc section size is ~16.5% for that one.

If you'd like to see the data in another format or see data for the benchmarks individually please let me know.

[dblaikie]

In D68620#2274165, @Orlando wrote:

@Orlando mentioned he was collecting some size data that would be relevant here, he'll post it when he's done. Basically .debug_loc sizes at various points.

Hi!

I've built a benchmark suite of 85 programs with "-O2 -g" with our downstream branch targeting X86 emitting DWARF v4.

This table provides a summary of the data. It shows the mean for some size data normalized as a percentage of the llvm-3 results for each benchmark.

For reference:
Largest binary built with llvm-3: 6010 kB
Smallest binary built with llvm-3: 79 kB

+------------------------------------------------------------------------------------------- +
| Mean binary size for benchmarks normalized as a percentage of llvm-3 builds                |
+---------------------------------+------------+------------------+-----------------+--------+
| llvm version                    | .debug_loc | other debug info | everything else | Total  |
+---------------------------------+------------+------------------+-----------------+--------+
| llvm-3                          | 13.7       | 33.2             | 53.1            | 100    |
| llvm-4                          | 12.7       | 33.8             | 53.8            | 100.3  |
| llvm-5                          | 13.4       | 35.6             | 54.6            | 103.7  |
| llvm-7                          | 18.4       | 35.6             | 54.0            | 108.0  |
| llvm-8                          | 17.5       | 37.1             | 54.5            | 109.1  |
| llvm-9                          | 19.7       | 37.2             | 54.6            | 111.5  |
| llvm-10 before dblaikie commit  | 19.8       | 37.4             | 54.9            | 112.1  |
| llvm-10 with dblaikie commit    | 25.6       | 37.4             | 54.9            | 117.9  |
| llvm-10                         | 25.8       | 37.5             | 54.8            | 118.1  |
| llvm-master before my commits   | 26.2       | 37.4             | 54.8            | 118.4  |
| llvm-master with my commits     | 18.4       | 35.5             | 55.3            | 109.3  |
+---------------------------------+------------+------------------+-----------------+--------+

Here's an image of that data in graph form: M3.

The llvm-6 entry has been omitted because the non debug-info size is a distracting outlier. The .debug_loc section size is ~16.5% for that one.

If you'd like to see the data in another format or see data for the benchmarks individually please let me know.

Thanks for the data!

(as an aside: do you/@probinson have much of a sense of how much binary size increase you'd trade for object size reductions in this space? If binary size is ulmtimately what you care most about, I'm guessing maybe debug_loc base address specifiers will never be a win for you & perhaps we should just group them under a flag, maybe refactor the debug_ranges base address specifier flag to cover both (the flag there was introduced due to a gold+gdb_index+32 bit binary bug, unfortunately, but lumping them together seems OK-ish to me))

When you say "llvm-master before/after your commits" - what version of llvm-master and what commits did you have to test with? (if you can/want to discuss them)

I'm rather surprised, if master was moderately recent, that it shows no benefit from https://reviews.llvm.org/rG57d8acac64b87cb4286b00485fb2da7521fc091e (perhaps, if it's not too much hassle, you could run a sample benchmark before/after that change?)

[Orlando]

Thanks for the data!

Happy to help :)

(as an aside: do you/@probinson have much of a sense of how much binary size increase you'd trade for object size reductions in this space? If binary size is ulmtimately what you care most about, I'm guessing maybe debug_loc base address specifiers will never be a win for you & perhaps we should just group them under a flag, maybe refactor the debug_ranges base address specifier flag to cover both (the flag there was introduced due to a gold+gdb_index+32 bit binary bug, unfortunately, but lumping them together seems OK-ish to me))

I'm not sure, I'll defer to @probinson on that.

When you say "llvm-master before/after your commits" - what version of llvm-master and what commits did you have to test with? (if you can/want to discuss them)

I'm rather surprised, if master was moderately recent, that it shows no benefit from https://reviews.llvm.org/rG57d8acac64b87cb4286b00485fb2da7521fc091e (perhaps, if it's not too much hassle, you could run a sample benchmark before/after that change?)

Apologies for being unclear. Stats for "before my commits" are taken from a build at the first commit before D79571, and "with my commits" is with D86153 / rG57d8acac64b87cb4286b00485fb2da7521fc091e applied (and all the commits in between, including D82129).

[dblaikie]

In D68620#2276034, @Orlando wrote:

Thanks for the data!

Happy to help :)

(as an aside: do you/@probinson have much of a sense of how much binary size increase you'd trade for object size reductions in this space? If binary size is ulmtimately what you care most about, I'm guessing maybe debug_loc base address specifiers will never be a win for you & perhaps we should just group them under a flag, maybe refactor the debug_ranges base address specifier flag to cover both (the flag there was introduced due to a gold+gdb_index+32 bit binary bug, unfortunately, but lumping them together seems OK-ish to me))

I'm not sure, I'll defer to @probinson on that.

When you say "llvm-master before/after your commits" - what version of llvm-master and what commits did you have to test with? (if you can/want to discuss them)

I'm rather surprised, if master was moderately recent, that it shows no benefit from https://reviews.llvm.org/rG57d8acac64b87cb4286b00485fb2da7521fc091e (perhaps, if it's not too much hassle, you could run a sample benchmark before/after that change?)

Apologies for being unclear. Stats for "before my commits" are taken from a build at the first commit before D79571, and "with my commits" is with D86153 / rG57d8acac64b87cb4286b00485fb2da7521fc091e applied (and all the commits in between, including D82129).

Ah, OK - so it sounds like we're back down below the size before I added debug_loc base address specifiers? That's good to hear!

If you're really interested in binary size, then, it might be worth an extra experiment to see what would happen if you disable base address specifiers - might still get you significantly below where we were before (now that the "don't use debug_loc so often" improvements have been made) - so there might still be some discussion about whether more selective use of base address selection entries would be good for you/others.

[Orlando]

Ah, OK - so it sounds like we're back down below the size before I added debug_loc base address specifiers? That's good to hear!

Yeah looks like it.

If you're really interested in binary size, then, it might be worth an extra experiment to see what would happen if you disable base address specifiers - might still get you significantly below where we were before (now that the "don't use debug_loc so often" improvements have been made) - so there might still be some discussion about whether more selective use of base address selection entries would be good for you/others.

SGTM I will have a look. To disable base address specifiers here is it enough to just pass in false for ShouldUseBaseAddress to emitRangeList on line DwarfDebug.cpp:2398?

[probinson]

In D68620#2276034, @Orlando wrote:

(as an aside: do you/@probinson have much of a sense of how much binary size increase you'd trade for object size reductions in this space? If binary size is ulmtimately what you care most about, I'm guessing maybe debug_loc base address specifiers will never be a win for you & perhaps we should just group them under a flag, maybe refactor the debug_ranges base address specifier flag to cover both (the flag there was introduced due to a gold+gdb_index+32 bit binary bug, unfortunately, but lumping them together seems OK-ish to me))

I'm not sure, I'll defer to @probinson on that.

What we actually care about is turnaround time, which for debug info encompasses compile time, link time, debugger startup time, and the attendant I/O latencies. Note that console download time is *not* a factor, as our downloader knows to omit the debug info.

It's not exactly raw size that matters, but we ought to care how efficiently the information is encoded in the file data. So, with respect to location/range lists, multiplying the number of entries without reducing the number of relocations is bad all around. The compiler has to produce more data; the linker has to copy more data, without any compensating reduction in relocation processing time; the debugger has to read more data to get the same information content.

Do we know how often a location/range list has a single non-base-address entry? Clearly we can avoid a list at all if the location/range aligns with the containing scope (the ValidThroughout case); single-entry lists would come up where that range is a subset of the containing scope, but still only needs one entry. In those cases, there's no object-file or final-binary benefit to having a base-address entry followed by a single list entry. And that optimization really wouldn't have to be under a flag, because it would always be a win, even in v5.
Apologies for not going to look myself...

[dblaikie]

In D68620#2279460, @probinson wrote:

In D68620#2276034, @Orlando wrote:

(as an aside: do you/@probinson have much of a sense of how much binary size increase you'd trade for object size reductions in this space? If binary size is ulmtimately what you care most about, I'm guessing maybe debug_loc base address specifiers will never be a win for you & perhaps we should just group them under a flag, maybe refactor the debug_ranges base address specifier flag to cover both (the flag there was introduced due to a gold+gdb_index+32 bit binary bug, unfortunately, but lumping them together seems OK-ish to me))

I'm not sure, I'll defer to @probinson on that.

What we actually care about is turnaround time, which for debug info encompasses compile time, link time, debugger startup time, and the attendant I/O latencies. Note that console download time is *not* a factor, as our downloader knows to omit the debug info.

It's not exactly raw size that matters, but we ought to care how efficiently the information is encoded in the file data. So, with respect to location lists, multiplying the number of entries without reducing the number of relocations is bad all around.

Agreed, though I don't think that's what we're doing here.

A single entry location list in DWARFv4 looks like this:

relocatable start address, relocatable end address

And at least on ELF x86_64, relocations are 3 times the size of an address, so the total size of that entry in the object file is (1 + 3) * 2 == 8

Whereas with a base address selection entry:

0xffffffffffffffff, relocatable address
start offset, end offset

So that's 1 + (1 + 3) + 1 + 1 == 7

So using a base address selection entry is a minor win in uncompressed object size - more significant win if you compress your .debug_info in object files (because relocations aren't compressed, so in the first case, only 1/4 of object file bytes are compressed, in the second case 4/7 bytes are compressed).

The compiler has to produce more data; the linker has to copy more data, without any compensating reduction in relocation processing time; the debugger has to read more data to get the same information content.

Do we know how often a location/range list has a single non-base-address entry?

aside: currently a range list never has a single entry, because we use low/high_pc then. Though per my thread from early this year, I think there might be some value in using range lists even in these single entry cases for the same reason as here with location lists - again, moreso in DWARFv5 (see below) than DWARFv4. (as a workaround for the lack of addrx+offset encoding which I'd use for low_pc otherwise and gain the same benefits - essentially allowing a "base address + offset pair" form of encoding for low/high pc, whereas it's currently more like "start address+length" encoding (akin to RLE_startx_length))

Clearly we can avoid a list at all if the location/range aligns with the containing scope (the ValidThroughout case); single-entry lists would come up where that range is a subset of the containing scope, but still only needs one entry. In those cases, there's no object-file or final-binary benefit to having a base-address entry followed by a single list entry. And that optimization really wouldn't have to be under a flag, because it would always be a win, even in v5.
Apologies for not going to look myself...

Not sure I understand - base address selection entries do have some benefit even for single entry lists. If they're explicitly worse across the board, yeah, I'd be all for not enabling this in single entry lists - but my understanding at the moment, and when I implemented it, was that it was still a (variable, depending on whether compressed debug info is used) win for object size and relocation count.

In v5 it's even more valuable, because you can share base addresses from other places. Imagine a location list for a scope inside a function. If we don't use a base address selection entry, it might be:

[DW_LLE_startx_length]:  uleb, uleb: location description
[DW_LLE_end_of_list  ]
...
debug_addr:
relocatable address

But with a base address selection entry, we can strategically choose an address that's already in the address pool:

[DW_LLE_startx_length]: uleb, uleb: location description
[DW_LLE_end_of_list  ]

Removing the address from the address pool entirely and instead relying on an existing one - at the cost of larger values, which in some cases would mean longer encoded ulebs - but given an entry in the address pool is 4 or 8 bytes + 3 times that in relocation, it's unlikely the ulebs would be long enough to favor the address pool entry instead.

In D68620#2278723, @Orlando wrote:

Ah, OK - so it sounds like we're back down below the size before I added debug_loc base address specifiers? That's good to hear!

Yeah looks like it.

Awesome, thanks for confirming/looking into it/etc!

If you're really interested in binary size, then, it might be worth an extra experiment to see what would happen if you disable base address specifiers - might still get you significantly below where we were before (now that the "don't use debug_loc so often" improvements have been made) - so there might still be some discussion about whether more selective use of base address selection entries would be good for you/others.

SGTM I will have a look. To disable base address specifiers here is it enough to just pass in false for ShouldUseBaseAddress to emitRangeList on line DwarfDebug.cpp:2398?

Yep, that ought to do it!

[Orlando]

I have here a copy of the table I shared earlier, with a new row "ShouldUseBaseAddress=false". The stats for this row are taken at 57d8acac64b (D86153) with the changes mentioned in my previous comment (disabling base address specifiers).

+------------------------------------------------------------------------------------------- +
| Mean binary size for benchmarks normalized as a percentage of llvm-3 builds                |
+---------------------------------+------------+------------------+-----------------+--------+
| llvm version                    | .debug_loc | other debug info | everything else | Total  |
+---------------------------------+------------+------------------+-----------------+--------+
| llvm-3                          | 13.7       | 33.2             | 53.1            | 100    |
| llvm-4                          | 12.7       | 33.8             | 53.8            | 100.3  |
| llvm-5                          | 13.4       | 35.6             | 54.6            | 103.7  |
| llvm-7                          | 18.4       | 35.6             | 54.0            | 108.0  |
| llvm-8                          | 17.5       | 37.1             | 54.5            | 109.1  |
| llvm-9                          | 19.7       | 37.2             | 54.6            | 111.5  |
| llvm-10 before dblaikie commit  | 19.8       | 37.4             | 54.9            | 112.1  |
| llvm-10 with dblaikie commit    | 25.6       | 37.4             | 54.9            | 117.9  |
| llvm-10                         | 25.8       | 37.5             | 54.8            | 118.1  |
| llvm-master before my commits   | 26.2       | 37.4             | 54.8            | 118.4  |
| llvm-master with my commits     | 18.4       | 35.5             | 55.3            | 109.3  |
| ShouldUseBaseAddress=false      | 14.9       | 35.5             | 55.3            | 105.7  |
+---------------------------------+------------+------------------+-----------------+--------+

When disabling the base address specifier - for these benchmarks (-O2 -gdwarf-4) - there is a 3.3% reduction in total file size again, with .debug_loc 19% smaller. This brings the binary sizes nearly in line with llvm-5.

I'm PTO tomorrow but I'd be happy to continue looking into this when I'm back if that would be useful.

[Orlando]

Out of curiosity I also did a clang-3.4 build too using master @ 485e6db8729 (3rd September) with "-O2 -gdwarf-4". It is smaller when disabling base address specifiers (and emitting DWARFv 4) too:
With base addresses (default): Total File Size: 527591064
Without base addresses: Total File Size: 513946184 (-2.59 %)

[dblaikie]

Thanks for all the data @Orlando - do you happen to have means to measure total object size too? Be useful to compare the binary size increase with the object size decrease.

[Orlando]

The following builds are with clang @ 485e6db8729 (3rd September) targeting x86.

+---------------------------------------------------------------+
| File size (bytes) of clang-3.4 built with -O2 -gdwarf-4       |
*===============================================================*
|                    | base addr    | no base addr | % change   |
+--------------------+--------------+--------------+------------+
| Accumulated object | 1874653208   | 1924003152   | +2.63      |
| file sizes         |              |              |            |
+--------------------+--------------+--------------+------------+
| Elf size           | 527591064    | 513946184    | -2.57      |
+--------------------+--------------+--------------+------------+

+---------------------------------------------------------------+
| File size (bytes) of clang-3.4 built with -O2 -gdwarf-5       |
*===============================================================*
|                    | base addr    | no base addr | % change   |
+--------------------+--------------+--------------+------------+
| Accumulated object | 1501490184   | 1515647496   | +0.94      |
| file sizes         |              |              |            |
+--------------------+--------------+--------------+------------+
| Elf size           | 478841560    | 478725248    | -0.024     |
+--------------------+--------------+--------------+------------+

The build time difference between all 4 configurations appears to be negligible. For both DWARFv5 and v5, when disabling base address entries, the object files are larger and elfs samller. The delta is more pronounced in DWARFv4, and the elf size reduction is very small for DWARFv5.

The following results are builds of a private benchmark suite (mentioned in previous comments) with downstream clang @ 57d8acac64b (27th August) targeting x86.

+---------------------------------------------------------------+
| File size (bytes) of benchmark suite built with -O2 -gdwarf-4 |
*===============================================================*
|                    | base addr    | no base addr | % change   |
+--------------------+--------------+--------------+------------+
| Accumulated object | 51828696     | 57886752     | +11.69     |
| file sizes         |              |              |            |
+--------------------+--------------+--------------+------------+
| Accumulated elf    | 43012748     | 41199724     | -4.22      |
| file sizes         |              |              |            |
+--------------------+--------------+--------------+------------+

The results are more extreme but follow the same pattern as the clang-3.4 builds. I don't have the build times or DWARFv5 builds to hand for these benchmarks.

[Orlando]

Just to clarify: when I say "elf" here I'm talking about the linked executable file, and "object files" are the pre-link .o files.

[dblaikie]

In D68620#2287669, @Orlando wrote:

Just to clarify: when I say "elf" here I'm talking about the linked executable file, and "object files" are the pre-link .o files.

Thanks - makes sense.

I guess all of these measurements were done without Split DWARF (shouldn't make things better/worse overall (across .o and .dwo), really, compared to DWARFv5 non-split - but means when only looking at .o files the difference of avoiding more debug_addr entries is more significant because there's fewer remaining .o debug bytes to begin with) and without compression (-gz) enabled?

@probinson - how're these tradeoffs all sounding to you, and did you have further thoughts on what sounds like somewhat of a source of confusion in the previous posts on this thread (the question of whether a base address selection entry for a one-entry list could be beneficial, which I believe it is/showed the numbers/my reasoning there)?

[Orlando]

I guess all of these measurements were done without Split DWARF (shouldn't make things better/worse overall (across .o and .dwo), really, compared to DWARFv5 non-split - but means when only looking at .o files the difference of avoiding more debug_addr entries is more significant because there's fewer remaining .o debug bytes to begin with) and without compression (-gz) enabled?

That's right; no split DWARF and no compression for any of those builds.

[probinson]

TL;DR: It's all good.

As I worked through the calculations again myself, I realized I had forgotten that both the start and end address in a v4 entry were relocated. (The spec says neither of them are; they are supposed to be relative to the CU base address. But nobody actually does it that way.) So in v4, using the base-address entry is a slight size win for object files, and reduces the total number of relocations. It has a cost in loadfile .debug_loc size, which is what people were noticing above.

And in v5, the combo of base_addressx/offset_pair is a win over startx_length because the former can reuse the .debug_addr entry for the function entry point. It shows up as in increase in .debug_loclists but there's a compensating decrease in .debug_addr as long as we actually do reuse a .debug_addr entry. Our debugger folks will whine about the additional indirection, but that's nothing new; v5 just has a lot more of that.

Orlando's data suggests that the overall build time difference is minimal. We have no data about debugger load times, but I'd hope that location lists wouldn't be on the critical path there.

My conclusion is: We have a better understanding of where the size difference is coming from; naively it doesn't cause turnaround-time problems. If we get complaints from licensees, we can revisit this, but I haven't been noticing size complaints in the last couple of years.

[dblaikie]

In D68620#2290273, @probinson wrote:

TL;DR: It's all good.

As I worked through the calculations again myself, I realized I had forgotten that both the start and end address in a v4 entry were relocated. (The spec says neither of them are; they are supposed to be relative to the CU base address. But nobody actually does it that way.)

Oh, they are relative to the CU base address, if there is one - but very few C++ CUs have a relocated base address - because they have code in multiple sections, they use DW_AT_ranges. If you make a simple CU with one function, then the CU gets a traditional low/high_pc - and, say, DW_AT_ranges on a scope inside that one function will be relative to the CU's base address (low_pc) and no relocations would be used (& even with base address selection entries in use - we won't emit a base address selection entry)

eg:

$ cat loc.cpp
void f1();
void f2() {
  int i = 7;
  f1();
  i = 3;
  f1();
}
void f3() {
}
$ clang++-tot loc.cpp -gdwarf-5 -c -O3 && llvm-dwarfdump-tot -v loc.o -debug-loclists
loc.o:  file format elf64-x86-64

.debug_loclists contents:
0x00000000: locations list header: length = 0x0000001b, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000001
offsets: [
0x00000004 => 0x00000010
]
0x00000010: 
            DW_LLE_offset_pair     (0x0000000000000001, 0x0000000000000006): DW_OP_consts +7, DW_OP_stack_value
            DW_LLE_offset_pair     (0x0000000000000006, 0x000000000000000c): DW_OP_consts +3, DW_OP_stack_value
            DW_LLE_end_of_list     ()

Compared to using function-sections, that'll put f2 and f3 in separate .text sections, forcing the use of DW_AT_ranges at the CU and then LLVM produces a constant zero value DW_AT_low_pc to be clear what the "base address" is (which means basically no base address - everything has to use absolute addressing/explicit base addresses in the range/loc lists):

$ clang++-tot -ffunction-sections loc.cpp -gdwarf-5 -c -O3 && llvm-dwarfdump-tot -v loc.o -debug-loclists
loc.o:  file format elf64-x86-64

.debug_loclists contents:
0x00000000: locations list header: length = 0x0000001d, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000001
offsets: [
0x00000004 => 0x00000010
]
0x00000010: 
            DW_LLE_base_addressx   (0x0000000000000000)
            DW_LLE_offset_pair     (0x0000000000000001, 0x0000000000000006): DW_OP_consts +7, DW_OP_stack_value
            DW_LLE_offset_pair     (0x0000000000000006, 0x000000000000000c): DW_OP_consts +3, DW_OP_stack_value
            DW_LLE_end_of_list     ()

So in v4, using the base-address entry is a slight size win for object files, and reduces the total number of relocations. It has a cost in loadfile .debug_loc size, which is what people were noticing above.

And in v5, the combo of base_addressx/offset_pair is a win over startx_length because the former can reuse the .debug_addr entry for the function entry point. It shows up as in increase in .debug_loclists but there's a compensating decrease in .debug_addr as long as we actually do reuse a .debug_addr entry. Our debugger folks will whine about the additional indirection, but that's nothing new; v5 just has a lot more of that.

Orlando's data suggests that the overall build time difference is minimal. We have no data about debugger load times, but I'd hope that location lists wouldn't be on the critical path there.

My conclusion is: We have a better understanding of where the size difference is coming from; naively it doesn't cause turnaround-time problems. If we get complaints from licensees, we can revisit this, but I haven't been noticing size complaints in the last couple of years.

Awesome awesome - really appreciate you talking through all this!

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

static MCSymbol *emitLoclistsTableHeader(AsmPrinter *Asm,
   // DW_AT_loclists_base attribute. Until then set the number of offsets to 0.
   Asm->OutStreamer->AddComment("Offset entry count");
   Asm->emitInt32(0);
   Asm->OutStreamer->EmitLabel(Holder.getLoclistsTableBaseSym());
 
   return TableEnd;
 }
 
-// Emit locations into the .debug_loc/.debug_rnglists section.
-void DwarfDebug::emitDebugLoc() {
-  if (DebugLocs.getLists().empty())
-    return;
+template <typename Ranges, typename PayloadEmitter>
+static void emitRangeList(
+    DwarfDebug &DD, AsmPrinter *Asm, MCSymbol *Sym, const Ranges &R,
+    const DwarfCompileUnit &CU, unsigned BaseAddressx, unsigned OffsetPair,
+    unsigned StartxLength, unsigned EndOfList,
+    StringRef (*StringifyEnum)(unsigned),
+    bool ShouldUseBaseAddress,
+    PayloadEmitter EmitPayload) {
 
-  bool IsLocLists = getDwarfVersion() >= 5;
-  MCSymbol *TableEnd = nullptr;
-  if (IsLocLists) {
-    Asm->OutStreamer->SwitchSection(
-        Asm->getObjFileLowering().getDwarfLoclistsSection());
-    TableEnd = emitLoclistsTableHeader(Asm, useSplitDwarf() ? SkeletonHolder
-                                                            : InfoHolder);
-  } else {
-    Asm->OutStreamer->SwitchSection(
-        Asm->getObjFileLowering().getDwarfLocSection());
-  }
+  auto Size = Asm->MAI->getCodePointerSize();
+  bool UseDwarf5 = DD.getDwarfVersion() >= 5;
 
-  unsigned char Size = Asm->MAI->getCodePointerSize();
-  for (const auto &List : DebugLocs.getLists()) {
-    Asm->OutStreamer->EmitLabel(List.Label);
+  // Emit our symbol so we can find the beginning of the range.
+  Asm->OutStreamer->EmitLabel(Sym);
 
-    const DwarfCompileUnit *CU = List.CU;
-    const MCSymbol *Base = CU->getBaseAddress();
-    for (const auto &Entry : DebugLocs.getEntries(List)) {
+  // Gather all the ranges that apply to the same section so they can share
+  // a base address entry.
+  MapVector<const MCSection *, std::vector<decltype(&*R.begin())>> SectionRanges;
+
+  for (const auto &Range : R)
+    SectionRanges[&Range.Begin->getSection()].push_back(&Range);
+
+  const MCSymbol *CUBase = CU.getBaseAddress();
+  bool BaseIsSet = false;
+  for (const auto &P : SectionRanges) {
+    auto *Base = CUBase;
+    if (!Base && ShouldUseBaseAddress) {
+      const MCSymbol *Begin = P.second.front()->Begin;
+      const MCSymbol *NewBase = DD.getSectionLabel(&Begin->getSection());
+      if (!UseDwarf5) {
+        Base = NewBase;
+        BaseIsSet = true;
+        Asm->OutStreamer->EmitIntValue(-1, Size);
+        Asm->OutStreamer->AddComment("  base address");
+        Asm->OutStreamer->EmitSymbolValue(Base, Size);
+      } else if (NewBase != Begin || P.second.size() > 1) {
+        // Only use a base address if
+        //  * the existing pool address doesn't match (NewBase != Begin)
+        //  * or, there's more than one entry to share the base address
+        Base = NewBase;
+        BaseIsSet = true;
+        Asm->OutStreamer->AddComment(StringifyEnum(BaseAddressx));
+        Asm->emitInt8(BaseAddressx);
+        Asm->OutStreamer->AddComment("  base address index");
+        Asm->EmitULEB128(DD.getAddressPool().getIndex(Base));
+      }
+    } else if (BaseIsSet && !UseDwarf5) {
+      BaseIsSet = false;
+      assert(!Base);
+      Asm->OutStreamer->EmitIntValue(-1, Size);
+      Asm->OutStreamer->EmitIntValue(0, Size);
+    }
+
+    for (const auto *RS : P.second) {
+      const MCSymbol *Begin = RS->Begin;
+      const MCSymbol *End = RS->End;
+      assert(Begin && "Range without a begin symbol?");
+      assert(End && "Range without an end symbol?");
       if (Base) {
-        // Set up the range. This range is relative to the entry point of the
-        // compile unit. This is a hard coded 0 for low_pc when we're emitting
-        // ranges, or the DW_AT_low_pc on the compile unit otherwise.
-        if (IsLocLists) {
-          Asm->OutStreamer->AddComment("DW_LLE_offset_pair");
-          Asm->OutStreamer->EmitIntValue(dwarf::DW_LLE_offset_pair, 1);
+        if (UseDwarf5) {
+          // Emit offset_pair when we have a base.
+          Asm->OutStreamer->AddComment(StringifyEnum(OffsetPair));
+          Asm->emitInt8(OffsetPair);
           Asm->OutStreamer->AddComment("  starting offset");
-          Asm->EmitLabelDifferenceAsULEB128(Entry.Begin, Base);
+          Asm->EmitLabelDifferenceAsULEB128(Begin, Base);
           Asm->OutStreamer->AddComment("  ending offset");
-          Asm->EmitLabelDifferenceAsULEB128(Entry.End, Base);
+          Asm->EmitLabelDifferenceAsULEB128(End, Base);
         } else {
-          Asm->EmitLabelDifference(Entry.Begin, Base, Size);
-          Asm->EmitLabelDifference(Entry.End, Base, Size);
-        }
-
-        emitDebugLocEntryLocation(Entry, CU);
-        continue;
+          Asm->EmitLabelDifference(Begin, Base, Size);
+          Asm->EmitLabelDifference(End, Base, Size);
         }
-
-      // We have no base address.
-      if (IsLocLists) {
-        // TODO: Use DW_LLE_base_addressx + DW_LLE_offset_pair, or
-        // DW_LLE_startx_length in case if there is only a single range.
-        // That should reduce the size of the debug data emited.
-        // For now just use the DW_LLE_startx_length for all cases.
-        Asm->OutStreamer->AddComment("DW_LLE_startx_length");
-        Asm->emitInt8(dwarf::DW_LLE_startx_length);
-        Asm->OutStreamer->AddComment("  start idx");
-        Asm->EmitULEB128(AddrPool.getIndex(Entry.Begin));
+      } else if (UseDwarf5) {
+        Asm->OutStreamer->AddComment(StringifyEnum(StartxLength));
+        Asm->emitInt8(StartxLength);
+        Asm->OutStreamer->AddComment("  start index");
+        Asm->EmitULEB128(DD.getAddressPool().getIndex(Begin));
         Asm->OutStreamer->AddComment("  length");
-        Asm->EmitLabelDifferenceAsULEB128(Entry.End, Entry.Begin);
+        Asm->EmitLabelDifferenceAsULEB128(End, Begin);
       } else {
-        Asm->OutStreamer->EmitSymbolValue(Entry.Begin, Size);
-        Asm->OutStreamer->EmitSymbolValue(Entry.End, Size);
-      }
-
-      emitDebugLocEntryLocation(Entry, CU);
-    }
+        Asm->OutStreamer->EmitSymbolValue(Begin, Size);
+        Asm->OutStreamer->EmitSymbolValue(End, Size);
+      }
+      EmitPayload(*RS);
 
-    if (IsLocLists) {
-      // .debug_loclists section ends with DW_LLE_end_of_list.
-      Asm->OutStreamer->AddComment("DW_LLE_end_of_list");
-      Asm->OutStreamer->EmitIntValue(dwarf::DW_LLE_end_of_list, 1);
-    } else {
-      // Terminate the .debug_loc list with two 0 values.
-      Asm->OutStreamer->EmitIntValue(0, Size);
-      Asm->OutStreamer->EmitIntValue(0, Size);
-    }
-  }
+  if (UseDwarf5) {
+    Asm->OutStreamer->AddComment(StringifyEnum(EndOfList));
+    Asm->emitInt8(EndOfList);
+    // Terminate the list with two 0 values.
 
+static void emitLocList(DwarfDebug &DD, AsmPrinter *Asm, const DebugLocStream::List &List) {
+  emitRangeList(
+      DD, Asm, List.Label, DD.getDebugLocs().getEntries(List), *List.CU,
+      dwarf::DW_LLE_base_addressx, dwarf::DW_LLE_offset_pair,
+      dwarf::DW_LLE_startx_length, dwarf::DW_LLE_end_of_list,
+      llvm::dwarf::LocListEncodingString,
+      /* ShouldUseBaseAddress */ true,
+      [&](const DebugLocStream::Entry &E) {
+        DD.emitDebugLocEntryLocation(E, List.CU);
+      });
+}
+
+// Emit locations into the .debug_loc/.debug_rnglists section.
+void DwarfDebug::emitDebugLoc() {
+  if (DebugLocs.getLists().empty())
+    return;
+
+  MCSymbol *TableEnd = nullptr;
+  if (getDwarfVersion() >= 5) {
+    Asm->OutStreamer->SwitchSection(
+        Asm->getObjFileLowering().getDwarfLoclistsSection());
+    TableEnd = emitLoclistsTableHeader(Asm, useSplitDwarf() ? SkeletonHolder
+                                                            : InfoHolder);
+  } else {
+    Asm->OutStreamer->SwitchSection(
+        Asm->getObjFileLowering().getDwarfLocSection());
+  }
+
+  for (const auto &List : DebugLocs.getLists())
+    emitLocList(*this, Asm, List);
+
   if (TableEnd)
     Asm->OutStreamer->EmitLabel(TableEnd);
 }
 
 void DwarfDebug::emitDebugLocDWO() {
   for (const auto &List : DebugLocs.getLists()) {
     Asm->OutStreamer->SwitchSection(
         Asm->getObjFileLowering().getDwarfLocDWOSection());
for (DwarfCompileUnit *CU : CUs) {
     }
 
     Asm->OutStreamer->AddComment("ARange terminator");
     Asm->OutStreamer->EmitIntValue(0, PtrSize);
     Asm->OutStreamer->EmitIntValue(0, PtrSize);
   }
 }
 
-template <typename Ranges>
-static void emitRangeList(DwarfDebug &DD, AsmPrinter *Asm, MCSymbol *Sym,
-                          const Ranges &R, const DwarfCompileUnit &CU,
-                          unsigned BaseAddressx, unsigned OffsetPair,
-                          unsigned StartxLength, unsigned EndOfList,
-                          StringRef (*StringifyEnum)(unsigned)) {
-  auto DwarfVersion = DD.getDwarfVersion();
-  // Emit our symbol so we can find the beginning of the range.
-  Asm->OutStreamer->EmitLabel(Sym);
-  // Gather all the ranges that apply to the same section so they can share
-  // a base address entry.
-  MapVector<const MCSection *, std::vector<const RangeSpan *>> SectionRanges;
-  // Size for our labels.
-  auto Size = Asm->MAI->getCodePointerSize();
-
-  for (const RangeSpan &Range : R)
-    SectionRanges[&Range.Begin->getSection()].push_back(&Range);
-
-  const MCSymbol *CUBase = CU.getBaseAddress();
-  bool BaseIsSet = false;
-  for (const auto &P : SectionRanges) {
-    // Don't bother with a base address entry if there's only one range in
-    // this section in this range list - for example ranges for a CU will
-    // usually consist of single regions from each of many sections
-    // (-ffunction-sections, or just C++ inline functions) except under LTO
-    // or optnone where there may be holes in a single CU's section
-    // contributions.
-    auto *Base = CUBase;
-    if (!Base && (P.second.size() > 1 || DwarfVersion < 5) &&
-        (CU.getCUNode()->getRangesBaseAddress() || DwarfVersion >= 5)) {
-      BaseIsSet = true;
-      Base = DD.getSectionLabel(&P.second.front()->Begin->getSection());
-      if (DwarfVersion >= 5) {
-        Asm->OutStreamer->AddComment(StringifyEnum(BaseAddressx));
-        Asm->OutStreamer->EmitIntValue(BaseAddressx, 1);
-        Asm->OutStreamer->AddComment("  base address index");
-        Asm->EmitULEB128(DD.getAddressPool().getIndex(Base));
-      } else {
-        Asm->OutStreamer->EmitIntValue(-1, Size);
-        Asm->OutStreamer->AddComment("  base address");
-        Asm->OutStreamer->EmitSymbolValue(Base, Size);
-      }
-    } else if (BaseIsSet && DwarfVersion < 5) {
-      BaseIsSet = false;
-      assert(!Base);
-      Asm->OutStreamer->EmitIntValue(-1, Size);
-      Asm->OutStreamer->EmitIntValue(0, Size);
-    }
-
-    for (const auto *RS : P.second) {
-      const MCSymbol *Begin = RS->Begin;
-      const MCSymbol *End = RS->End;
-      assert(Begin && "Range without a begin symbol?");
-      assert(End && "Range without an end symbol?");
-      if (Base) {
-        if (DwarfVersion >= 5) {
-          // Emit DW_RLE_offset_pair when we have a base.
-          Asm->OutStreamer->AddComment(StringifyEnum(OffsetPair));
-          Asm->emitInt8(OffsetPair);
-          Asm->OutStreamer->AddComment("  starting offset");
-          Asm->EmitLabelDifferenceAsULEB128(Begin, Base);
-          Asm->OutStreamer->AddComment("  ending offset");
-          Asm->EmitLabelDifferenceAsULEB128(End, Base);
-        } else {
-          Asm->EmitLabelDifference(Begin, Base, Size);
-          Asm->EmitLabelDifference(End, Base, Size);
-        }
-      } else if (DwarfVersion >= 5) {
-        Asm->OutStreamer->AddComment(StringifyEnum(StartxLength));
-        Asm->emitInt8(StartxLength);
-        Asm->OutStreamer->AddComment("  start index");
-        Asm->EmitULEB128(DD.getAddressPool().getIndex(Begin));
-        Asm->OutStreamer->AddComment("  length");
-        Asm->EmitLabelDifferenceAsULEB128(End, Begin);
-      } else {
-        Asm->OutStreamer->EmitSymbolValue(Begin, Size);
-        Asm->OutStreamer->EmitSymbolValue(End, Size);
-      }
-    }
-  }
-  if (DwarfVersion >= 5) {
-    Asm->OutStreamer->AddComment(StringifyEnum(EndOfList));
-    Asm->emitInt8(EndOfList);
-  } else {
-    // Terminate the list with two 0 values.
-    Asm->OutStreamer->EmitIntValue(0, Size);
-    Asm->OutStreamer->EmitIntValue(0, Size);
-  }
-}
-
 /// Emit a single range list. We handle both DWARF v5 and earlier.
 static void emitRangeList(DwarfDebug &DD, AsmPrinter *Asm,
                           const RangeSpanList &List) {
   emitRangeList(DD, Asm, List.getSym(), List.getRanges(), List.getCU(),
                 dwarf::DW_RLE_base_addressx, dwarf::DW_RLE_offset_pair,
                 dwarf::DW_RLE_startx_length, dwarf::DW_RLE_end_of_list,
-                llvm::dwarf::RangeListEncodingString);
+                llvm::dwarf::RangeListEncodingString,
+                List.getCU().getCUNode()->getRangesBaseAddress() ||
+                    DD.getDwarfVersion() >= 5,
+                [](auto) {});
 }
 
 static void emitDebugRangesImpl(DwarfDebug &DD, AsmPrinter *Asm,
                                 const DwarfFile &Holder, MCSymbol *TableEnd) {
   for (const RangeSpanList &List : Holder.getRangeLists())
     emitRangeList(DD, Asm, List);
 
   if (TableEnd)

llvm/test/CodeGen/X86/debug-loclists.ll

-; RUN: llc -mtriple=x86_64-pc-linux -filetype=obj -o %t < %s
-; RUN: llvm-dwarfdump -v %t | FileCheck %s
+; RUN: llc -mtriple=x86_64-pc-linux -filetype=obj -function-sections -o %t < %s
+; RUN: llvm-dwarfdump -v -debug-info -debug-loclists %t | FileCheck %s
 
-; CHECK:      0x00000033: DW_TAG_formal_parameter [3]
-; CHECK-NEXT:               DW_AT_location [DW_FORM_sec_offset]   (0x0000000c
-; CHECK-NEXT:                  [0x0000000000000000, 0x0000000000000004): DW_OP_breg5 RDI+0
-; CHECK-NEXT:                  [0x0000000000000004, 0x0000000000000012): DW_OP_breg3 RBX+0)
-; CHECK-NEXT:               DW_AT_name [DW_FORM_strx1]    (indexed (0000000e) string = "a")
-; CHECK-NEXT:               DW_AT_decl_file [DW_FORM_data1]       ("/home/folder{{\\|\/}}test.cc")
-; CHECK-NEXT:               DW_AT_decl_line [DW_FORM_data1]       (6)
-; CHECK-NEXT:               DW_AT_type [DW_FORM_ref4]     (cu + 0x0040 => {0x00000040} "A")
+; CHECK:      DW_TAG_variable
+; FIXME: Use DW_FORM_loclistx to reduce relocations
+; CHECK-NEXT:   DW_AT_location [DW_FORM_sec_offset]   (0x0000000c
+; CHECK-NEXT:     [0x0000000000000000, 0x0000000000000003): DW_OP_consts +3, DW_OP_stack_value
+; CHECK-NEXT:     [0x0000000000000003, 0x0000000000000004): DW_OP_consts +4, DW_OP_stack_value)
+; CHECK-NEXT:   DW_AT_name {{.*}} "y"
+
+; CHECK:      DW_TAG_variable
+; FIXME: Use DW_FORM_loclistx to reduce relocations
+; CHECK-NEXT:   DW_AT_location [DW_FORM_sec_offset]   (0x0000001d
+; CHECK-NEXT:     Addr idx 0 (w/ length 3): DW_OP_consts +5, DW_OP_stack_value)
+; CHECK-NEXT:   DW_AT_name {{.*}} "x"
+
+; CHECK:      DW_TAG_variable
+; FIXME: Use DW_FORM_loclistx to reduce relocations
+; CHECK-NEXT:   DW_AT_location [DW_FORM_sec_offset]   (0x00000025
+; CHECK-NEXT:     [0x0000000000000003, 0x0000000000000004): DW_OP_reg0 RAX)
+; CHECK-NEXT:   DW_AT_name {{.*}} "r"
 
 ; CHECK:      .debug_loclists contents:
-; CHECK-NEXT: 0x00000000: locations list header: length = 0x00000015, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000000
-; CHECK-NEXT: 0x0000000c:
-; CHECK-NEXT: DW_LLE_offset_pair(0x0000000000000000, 0x0000000000000004)
-; CHECK-NEXT:                => [0x0000000000000000, 0x0000000000000004): DW_OP_breg5 RDI+0
-; CHECK-NEXT: DW_LLE_offset_pair(0x0000000000000004, 0x0000000000000012)
-; CHECK-NEXT:                => [0x0000000000000004, 0x0000000000000012): DW_OP_breg3 RBX+0
-
-; There is no way to use llvm-dwarfdump atm (2018, october) to verify the DW_LLE_* codes emited,
-; because dumper is not yet implements that. Use asm code to do this check instead.
-;
-; RUN: llc -mtriple=x86_64-pc-linux -filetype=asm < %s -o - | FileCheck %s --check-prefix=ASM
-; ASM:      .section .debug_loclists,"",@progbits
-; ASM-NEXT: .long .Ldebug_loclist_table_end0-.Ldebug_loclist_table_start0 # Length
-; ASM-NEXT: .Ldebug_loclist_table_start0:
-; ASM-NEXT:  .short 5                              # Version
-; ASM-NEXT:  .byte 8                               # Address size
-; ASM-NEXT:  .byte 0                               # Segment selector size
-; ASM-NEXT:  .long 0                               # Offset entry count
-; ASM-NEXT: .Lloclists_table_base0:                
-; ASM-NEXT: .Ldebug_loc0:
-; ASM-NEXT:  .byte 4                               # DW_LLE_offset_pair
-; ASM-NEXT:  .uleb128 .Lfunc_begin0-.Lfunc_begin0  # starting offset
-; ASM-NEXT:  .uleb128 .Ltmp0-.Lfunc_begin0         # ending offset
-; ASM-NEXT:  .byte 2                               # Loc expr size
-; ASM-NEXT:  .byte 117                             # DW_OP_breg5
-; ASM-NEXT:  .byte 0                               # 0
-; ASM-NEXT:  .byte 4                               # DW_LLE_offset_pair
-; ASM-NEXT:  .uleb128 .Ltmp0-.Lfunc_begin0         # starting offset
-; ASM-NEXT:  .uleb128 .Ltmp1-.Lfunc_begin0         # ending offset
-; ASM-NEXT:  .byte 2                               # Loc expr size
-; ASM-NEXT:  .byte 115                             # DW_OP_breg3
-; ASM-NEXT:  .byte 0                               # 0
-; ASM-NEXT:  .byte 0                               # DW_LLE_end_of_list
-; ASM-NEXT: .Ldebug_loclist_table_end0:
-
-; ModuleID = 'test.cc'
-source_filename = "test.cc"
-target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
-target triple = "x86_64-unknown-linux-gnu"
-
-%struct.A = type { i32 (...)** }
-
-@_ZTV1A = dso_local unnamed_addr constant { [4 x i8*] } { [4 x i8*] [i8* null, i8* bitcast ({ i8*, i8* }* @_ZTI1A to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A3fooEv to i8*), i8* bitcast (void (%struct.A*)* @_ZN1A3barEv to i8*)] }, align 8
-@_ZTVN10__cxxabiv117__class_type_infoE = external dso_local global i8*
-@_ZTS1A = dso_local constant [3 x i8] c"1A\00", align 1
-@_ZTI1A = dso_local constant { i8*, i8* } { i8* bitcast (i8** getelementptr inbounds (i8*, i8** @_ZTVN10__cxxabiv117__class_type_infoE, i64 2) to i8*), i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1A, i32 0, i32 0) }, align 8
+; CHECK-NEXT: 0x00000000: locations list header: length = 0x00000029, version = 0x0005, addr_size = 0x08, seg_size = 0x00, offset_entry_count = 0x00000000
 
-; Function Attrs: noinline optnone uwtable
-define dso_local void @_Z3baz1A(%struct.A* %a) #0 !dbg !7 {
-entry:
-  call void @llvm.dbg.declare(metadata %struct.A* %a, metadata !23, metadata !DIExpression()), !dbg !24
-  call void @_ZN1A3fooEv(%struct.A* %a), !dbg !25
-  call void @_ZN1A3barEv(%struct.A* %a), !dbg !26
-  ret void, !dbg !27
-}
+; Don't use startx_length if there's more than one entry, because the shared
+; base address will be useful for both the range that does start at the start of
+; the function, and the one that doesn't.
 
-; Function Attrs: nounwind readnone speculatable
-declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+; CHECK-NEXT: 0x0000000c:
+; CHECK-NEXT:             DW_LLE_base_addressx(0x0000000000000000)
+; CHECK-NEXT:             DW_LLE_offset_pair  (0x0000000000000000, 0x0000000000000003)
+; CHECK-NEXT:                              => [0x0000000000000000, 0x0000000000000003): DW_OP_consts +3, DW_OP_stack_value
+; CHECK-NEXT:             DW_LLE_offset_pair  (0x0000000000000003, 0x0000000000000004)
+; CHECK-NEXT:                              => [0x0000000000000003, 0x0000000000000004): DW_OP_consts +4, DW_OP_stack_value
+; CHECK-NEXT:             DW_LLE_end_of_list  ()
+
+; Show that startx_length can be used when the address range starts at the start of the function.
+
+; CHECK:      0x0000001d:
+; CHECK-NEXT:             DW_LLE_startx_length(0x0000000000000000, 0x0000000000000003)
+; CHECK-NEXT:                              => Addr idx 0 (w/ length 3): DW_OP_consts +5, DW_OP_stack_value
+; CHECK-NEXT:             DW_LLE_end_of_list  ()
+
+; And use a base address when the range doesn't start at an existing/useful
+; address in the pool.
+
+; CHECK:      0x00000025:
+; CHECK-NEXT:             DW_LLE_base_addressx(0x0000000000000000)
+; CHECK-NEXT:             DW_LLE_offset_pair  (0x0000000000000003, 0x0000000000000004)
+; CHECK-NEXT:                              => [0x0000000000000003, 0x0000000000000004): DW_OP_reg0 RAX
+; CHECK-NEXT:             DW_LLE_end_of_list  ()
 
-; Function Attrs: noinline nounwind optnone uwtable
-define dso_local void @_ZN1A3fooEv(%struct.A* %this) unnamed_addr #2 align 2 !dbg !28 {
-entry:
-  %this.addr = alloca %struct.A*, align 8
-  store %struct.A* %this, %struct.A** %this.addr, align 8
-  call void @llvm.dbg.declare(metadata %struct.A** %this.addr, metadata !29, metadata !DIExpression()), !dbg !31
-  %this1 = load %struct.A*, %struct.A** %this.addr, align 8
-  ret void, !dbg !32
-}
+; Built with clang -O3 -ffunction-sections from source:
+; 
+; int f1(int i, int j) {
+;   int x = 5;
+;   int y = 3;
+;   int r = i + j;
+;   int undef;
+;   x = undef;
+;   y = 4;
+;   return r;
+; }
+; void f2() {
+; }
 
-; Function Attrs: noinline nounwind optnone uwtable
-define dso_local void @_ZN1A3barEv(%struct.A* %this) unnamed_addr #2 align 2 !dbg !33 {
+; Function Attrs: norecurse nounwind readnone uwtable
+define dso_local i32 @_Z2f1ii(i32 %i, i32 %j) local_unnamed_addr !dbg !7 {
 entry:
-  %this.addr = alloca %struct.A*, align 8
-  store %struct.A* %this, %struct.A** %this.addr, align 8
-  call void @llvm.dbg.declare(metadata %struct.A** %this.addr, metadata !34, metadata !DIExpression()), !dbg !35
-  %this1 = load %struct.A*, %struct.A** %this.addr, align 8
-  ret void, !dbg !36
+  call void @llvm.dbg.value(metadata i32 %i, metadata !12, metadata !DIExpression()), !dbg !18
+  call void @llvm.dbg.value(metadata i32 %j, metadata !13, metadata !DIExpression()), !dbg !18
+  call void @llvm.dbg.value(metadata i32 5, metadata !14, metadata !DIExpression()), !dbg !18
+  call void @llvm.dbg.value(metadata i32 3, metadata !15, metadata !DIExpression()), !dbg !18
+  %add = add nsw i32 %j, %i, !dbg !19
+  call void @llvm.dbg.value(metadata i32 %add, metadata !16, metadata !DIExpression()), !dbg !18
+  call void @llvm.dbg.value(metadata i32 undef, metadata !14, metadata !DIExpression()), !dbg !18
+  call void @llvm.dbg.value(metadata i32 4, metadata !15, metadata !DIExpression()), !dbg !18
+  ret i32 %add, !dbg !20
 }
 
-; Function Attrs: noinline norecurse nounwind optnone uwtable
-define dso_local i32 @main() #3 !dbg !37 {
+; Function Attrs: norecurse nounwind readnone uwtable
+define dso_local void @_Z2f2v() local_unnamed_addr !dbg !21 {
 entry:
-  %retval = alloca i32, align 4
-  store i32 0, i32* %retval, align 4
-  ret i32 0, !dbg !38
+  ret void, !dbg !24
 }
 
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata)
 
 !llvm.dbg.cu = !{!0}
 !llvm.module.flags = !{!3, !4, !5}
 !llvm.ident = !{!6}
 
-!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 8.0.0 (trunk 344035)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
-!1 = !DIFile(filename: "test.cc", directory: "/home/folder", checksumkind: CSK_MD5, checksum: "e0f357ad6dcb791a774a0dae55baf5e7")
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 10.0.0 (trunk 374581) (llvm/trunk 374579)", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "loc2.cpp", directory: "/usr/local/google/home/blaikie/dev/scratch", checksumkind: CSK_MD5, checksum: "91e0069c680e2a63f4f885ec93f5d07e")
 !2 = !{}
 !3 = !{i32 2, !"Dwarf Version", i32 5}
 !4 = !{i32 2, !"Debug Info Version", i32 3}
 !5 = !{i32 1, !"wchar_size", i32 4}
-!6 = !{!"clang version 8.0.0 (trunk 344035)"}
-!7 = distinct !DISubprogram(name: "baz", linkageName: "_Z3baz1A", scope: !1, file: !1, line: 6, type: !8, isLocal: false, isDefinition: true, scopeLine: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
+!6 = !{!"clang version 10.0.0 (trunk 374581) (llvm/trunk 374579)"}
+!7 = distinct !DISubprogram(name: "f1", linkageName: "_Z2f1ii", scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !11)
 !8 = !DISubroutineType(types: !9)
-!9 = !{null, !10}
-!10 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "A", file: !1, line: 1, size: 64, flags: DIFlagTypePassByReference, elements: !11, vtableHolder: !10, identifier: "_ZTS1A")
-!11 = !{!12, !18, !22}
-!12 = !DIDerivedType(tag: DW_TAG_member, name: "_vptr$A", scope: !1, file: !1, baseType: !13, size: 64, flags: DIFlagArtificial)
-!13 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !14, size: 64)
-!14 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "__vtbl_ptr_type", baseType: !15, size: 64)
-!15 = !DISubroutineType(types: !16)
-!16 = !{!17}
-!17 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
-!18 = !DISubprogram(name: "foo", linkageName: "_ZN1A3fooEv", scope: !10, file: !1, line: 2, type: !19, isLocal: false, isDefinition: false, scopeLine: 2, containingType: !10, virtuality: DW_VIRTUALITY_virtual, virtualIndex: 0, flags: DIFlagPrototyped, isOptimized: false)
-!19 = !DISubroutineType(types: !20)
-!20 = !{null, !21}
-!21 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !10, size: 64, flags: DIFlagArtificial | DIFlagObjectPointer)
-!22 = !DISubprogram(name: "bar", linkageName: "_ZN1A3barEv", scope: !10, file: !1, line: 3, type: !19, isLocal: false, isDefinition: false, scopeLine: 3, containingType: !10, virtuality: DW_VIRTUALITY_virtual, virtualIndex: 1, flags: DIFlagPrototyped, isOptimized: false)
-!23 = !DILocalVariable(name: "a", arg: 1, scope: !7, file: !1, line: 6, type: !10)
-!24 = !DILocation(line: 6, column: 19, scope: !7)
-!25 = !DILocation(line: 7, column: 6, scope: !7)
-!26 = !DILocation(line: 8, column: 6, scope: !7)
-!27 = !DILocation(line: 9, column: 1, scope: !7)
-!28 = distinct !DISubprogram(name: "foo", linkageName: "_ZN1A3fooEv", scope: !10, file: !1, line: 12, type: !19, isLocal: false, isDefinition: true, scopeLine: 12, flags: DIFlagPrototyped, isOptimized: false, unit: !0, declaration: !18, retainedNodes: !2)
-!29 = !DILocalVariable(name: "this", arg: 1, scope: !28, type: !30, flags: DIFlagArtificial | DIFlagObjectPointer)
-!30 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !10, size: 64)
-!31 = !DILocation(line: 0, scope: !28)
-!32 = !DILocation(line: 12, column: 16, scope: !28)
-!33 = distinct !DISubprogram(name: "bar", linkageName: "_ZN1A3barEv", scope: !10, file: !1, line: 13, type: !19, isLocal: false, isDefinition: true, scopeLine: 13, flags: DIFlagPrototyped, isOptimized: false, unit: !0, declaration: !22, retainedNodes: !2)
-!34 = !DILocalVariable(name: "this", arg: 1, scope: !33, type: !30, flags: DIFlagArtificial | DIFlagObjectPointer)
-!35 = !DILocation(line: 0, scope: !33)
-!36 = !DILocation(line: 13, column: 16, scope: !33)
-!37 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 15, type: !15, isLocal: false, isDefinition: true, scopeLine: 15, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
-!38 = !DILocation(line: 16, column: 3, scope: !37)
+!9 = !{!10, !10, !10}
+!10 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!11 = !{!12, !13, !14, !15, !16, !17}
+!12 = !DILocalVariable(name: "i", arg: 1, scope: !7, file: !1, line: 1, type: !10)
+!13 = !DILocalVariable(name: "j", arg: 2, scope: !7, file: !1, line: 1, type: !10)
+!14 = !DILocalVariable(name: "x", scope: !7, file: !1, line: 2, type: !10)
+!15 = !DILocalVariable(name: "y", scope: !7, file: !1, line: 3, type: !10)
+!16 = !DILocalVariable(name: "r", scope: !7, file: !1, line: 4, type: !10)
+!17 = !DILocalVariable(name: "undef", scope: !7, file: !1, line: 5, type: !10)
+!18 = !DILocation(line: 0, scope: !7)
+!19 = !DILocation(line: 4, column: 13, scope: !7)
+!20 = !DILocation(line: 8, column: 3, scope: !7)
+!21 = distinct !DISubprogram(name: "f2", linkageName: "_Z2f2v", scope: !1, file: !1, line: 10, type: !22, scopeLine: 10, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !2)
+!22 = !DISubroutineType(types: !23)
+!23 = !{null}
+!24 = !DILocation(line: 11, column: 1, scope: !21)

llvm/test/DebugInfo/X86/sret.ll

 ; RUN: llc -split-dwarf-file=foo.dwo -O0 %s -mtriple=x86_64-unknown-linux-gnu -filetype=obj -o %t
 ; RUN: llvm-dwarfdump -v -all %t | FileCheck %s --check-prefix=CHECK-DWO
 
 ; Based on the debuginfo-tests/sret.cpp code.
 
 ; CHECK-DWO: DW_AT_GNU_dwo_id [DW_FORM_data8] (0x51ac5644b1937aa1)
 ; CHECK-DWO: DW_AT_GNU_dwo_id [DW_FORM_data8] (0x51ac5644b1937aa1)
 
 ; RUN: llc -O0 -fast-isel=true -mtriple=x86_64-apple-darwin -filetype=obj -o - %s | llvm-dwarfdump -v - | FileCheck %s
 ; RUN: llc -O0 -fast-isel=false -mtriple=x86_64-apple-darwin -filetype=obj -o - %s | llvm-dwarfdump -v - | FileCheck %s
 ; CHECK: _ZN1B9AInstanceEv
 ; CHECK: DW_TAG_variable
 ; CHECK-NEXT:   DW_AT_location [DW_FORM_sec_offset] (0x00000000
+; CHECK-NEXT:     [0xffffffffffffffff, {{.*}}): {{$}}
 ; CHECK-NEXT:     [{{.*}}, {{.*}}): DW_OP_breg5 RDI+0
 ; CHECK-NEXT:     [{{.*}}, {{.*}}): DW_OP_breg6 RBP-24, DW_OP_deref)
 ; CHECK-NEXT:   DW_AT_name {{.*}}"a"
 
 %class.A = type { i32 (...)**, i32 }
 %class.B = type { i8 }
 
 @_ZTV1A = linkonce_odr unnamed_addr constant [4 x i8*] [i8* null, i8* bitcast ({ i8*, i8* }* @_ZTI1A to i8*), i8* bitcast (void (%class.A*)* @_ZN1AD2Ev to i8*), i8* bitcast (void (%class.A*)* @_ZN1AD0Ev to i8*)]