[PATCH] D68620: DebugInfo: Use base address selection entries for debug_loc

Thu Sep 17 13:25:03 PDT 2020

dblaikie added a comment.

In D68620#2279460 <https://reviews.llvm.org/D68620#2279460>, @probinson wrote:

> In D68620#2276034 <https://reviews.llvm.org/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 <https://reviews.llvm.org/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!

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68620/new/

https://reviews.llvm.org/D68620