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

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68620