[PATCH] D36097: Prototype fix for lld DWARF parsing of base address selection entries in range lists

George Rimar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 28 08:15:20 PDT 2017


grimar added inline comments.


================
Comment at: lib/DebugInfo/DWARF/DWARFUnit.cpp:247
+    if (auto BaseAddr = toAddress(LowPCDie))
+      setBaseAddress(*BaseAddr, LowPCDie->getSectionIndex());
     AddrOffsetSectionBase = toSectionOffset(UnitDie.find(DW_AT_GNU_addr_base), 0);
----------------
I debugged this patch today and tried to use `Optional<BaseAddr>` here for `setBaseAddress`,
where `BaseAddr` was a struct for address and section index pair:

```
struct BaseAddress {
  uint64_t Address;
  uint64_t SectionIndex;
};
```

But I faced following issues when
run tests from `llvm\test\DebugInfo\X86` and I am not sure how to resolve them correctly. 

1) I had to implement `setBaseAddress` in next way:
```
  void setBaseAddress(BaseAddress BaseAddr) {
    if (!BaseAddr.Address && BaseAddr.SectionIndex == -1ULL)
      return;
    assert(BaseAddr.SectionIndex != -1ULL);
    this->BaseAddr = BaseAddr;
  }
```

I can not justify first 2 lines for myself though. it looks that is is common that CU has `DW_AT_low_pc` set to 0
without corresponding relocation.

For example I can take following code and invocation:

```
# clang test.cpp -S -o test.s -gmlt -ffunction-sections
# test.cpp:
#   void foo1() { }  
#   void foo2() { }  
```

And .debug_info section will be:

```
	.section	.debug_info,"", at progbits
.Lcu_begin0:
......
	.long	.Linfo_string2          # DW_AT_comp_dir
	.quad	0                       # DW_AT_low_pc
	.long	.Ldebug_ranges0         # DW_AT_ranges

```

So DW_AT_low_pc will present in CU, but be zero and have no relocation.

Can we safely filter such cases out, like I did in my version of `setBaseAddress` above ?
Not sure why DW_AT_low_pc is ever emited then, it looks useless.

2) Even with above change, there is still testcase that fails my new assertion `assert(BaseAddr.SectionIndex != -1ULL);`. 
It is `DebugInfo/X86/stmt-list-multiple-compile-units.ll`.
It has `DW_AT_low_pc == 0x10` but still no corresponding relocation and so it can not find the section index.

That happens because `DWARFObjInMemory` has following code that skips scanning relocations:

```
     // In Mach-o files, the relocations do not need to be applied if
      // there is no load offset to apply. The value read at the
      // relocation point already factors in the section address
      // (actually applying the relocations will produce wrong results
      // as the section address will be added twice).
      if (!L && isa<MachOObjectFile>(&Obj))
        continue;
```

So relocations are in the file, but we do not read them at all for MachO. And unable to get section index so far.
I guess correct way would be to enable scanning and storing them, but still skip applying somehow. 
Does it make sence ?

FWIW, I uploaded what I have here: D37214. It passes all tests now (assertion I mentioned is removed).


https://reviews.llvm.org/D36097





More information about the llvm-commits mailing list