dwarfdump: Support/process relocations on a CU's abbrev_off

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
This commit is contained in:
David Blaikie 2016-12-16 16:31:10 +00:00
parent 6db0eaf697
commit b50f7b927b
3 changed files with 11 additions and 0 deletions

View File

@ -87,7 +87,10 @@ bool DWARFUnit::getStringOffsetSectionItem(uint32_t Index,
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;

Binary file not shown.

View File

@ -0,0 +1,8 @@
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