Add support for base address entries in the .debug_ranges section


Add support for base address entries in the .debug_ranges section

Clang recently started to emit base address entries into the
.debug_ranges section to reduce the number of relocations needed. Lets
make sure LLDB can read them.


tberghammerJul 31 2017, 3:26 AM
rL309553: Guard print() functions only used by dump() functions.

Event Timeline

dblaikie added inline comments.

This looks incorrect - there's an assumed base address: "If there is no such selection entry, then the applicable base address defaults to the base address of the compilation unit"

You can observe this with clang producing a range list relying on this default base address with code like this:

__attribute__((pure)) int f1();
void f2();
bool f3(bool);
void f4(int);
void f1(bool x) {
  int i = f1();
  if (bool c = f3(x)) {

Clang produces debug_ranges that includes no relocations, because the values should be interpreted relative to the base address of the CU which is the low_pc value.

It's possible this is handled elsewhere in LLDB, I guess? But then it wouldn't correctly handle the use of an explicit low_pc as a default base address in the presence of ranges. (Clang doesn't use this, but could - if a bunch of functions were in different sections, but most of them are in the plain .text section, DWARF supports specifying DW_AT_ranges /and/ DW_AT_low_pc, where the latter is used as the default base address for ranges and loc lists)

So I guess two things:

  1. is a default base address supported at all (Clang does this today, and must do so, though it might not come up often, since it only happens if all the code is in one section - rare in C++ due to inline functions)
  2. is it supported in a range list that also has non-default base address specifiers (Clang doesn't do this today, but could be a minor optimization in the future)
tberghammer added inline comments.Aug 30 2017, 3:07 PM

Thank you for checking out this patch. I verified that LLDB handles the first case by unconditionally sliding the range definitions by the compile unit base address (if specified) what means that the 1st case is handled correctly but the 2nd case is not. I will try to fix it when I have some time (hopefully in the near future).