[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