A recent improvement to LLVM produces DWARF compliant, but (apparently)
infrequently used range lists - using base address selection entries to
reduce the number of relocations required (& reduce file size &
hopefully link time)
This breaks lld's use of LLVM's libDebugInfo which isn't correctly
tracking the section index in the presence of this kind of debug info.
Here's my first blush at a fix for libDebugInfo - though it does rais
some questions and needs testing (is there any testing in LLVM (not lld)
for the section index API in libDebugInfo? it'd be good if there was,
maybe API level testing).
How should/does this differentiate between the case where the unit's
base address is actually zero? compared to when it's not present? Does
that matter? I'm not sure.
(aside: does anyone have an idea of how well LLD scales with the number of
relocations versus the number of bytes of data in a section? I'd love to know
how much this reduction in relocations is worth (like is runtime of the linker
roughly N*relocs + M*raw bytes? Could be interesting to know - obviously
varying on different configurations (cores, disk speed, etc))
So DWARF spec says:
The applicable base address of a range list entry is determined by the closest preceding base
address selection entry (see below) in the same range list. If there is no such selection entry, then
the applicable base address defaults to the base address of the compilation unit (see Section
3.1.1).
Should BaseAddress and SectionIndex be optional then ? Then code can be like following probably: