Input can be produced by ld -r, for example (a normal LLVM workflow
never hits this - LLVM only ever produces a single abbrev table in an
object (shared by multiple CUs), so the reloc's always 0, and when it's
linked together the relocation's resolved so it doesn't need to be
handled)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289954
91177308-0d34-0410-b5e6-
96231b3b80d8
bool DWARFUnit::extractImpl(DataExtractor debug_info, uint32_t *offset_ptr) {
Length = debug_info.getU32(offset_ptr);
Version = debug_info.getU16(offset_ptr);
+ auto AI = InfoSection.Relocs.find(*offset_ptr);
uint64_t AbbrOffset = debug_info.getU32(offset_ptr);
+ if (AI != InfoSection.Relocs.end())
+ AbbrOffset += AI->second.second;
if (IndexEntry) {
if (AbbrOffset)
return false;
--- /dev/null
+RUN: llvm-dwarfdump -debug-dump=info %p/Inputs/dwarfdump-abbrev-off.elf-x86-64 | FileCheck %s
+
+Check that we apply relocations to the abbr_offset - while LLVM never produces
+an object file like this, a reproduction can be produced by linking two simple
+object files together with ld -r.
+
+CHECK: abbr_offset = 0x0000
+CHECK: abbr_offset = 0x0010