llvm-objdump doesn't support RELR

[dwblaikie]

Seems llvm-readobj does support dumping relr relocations, but llvm-objdump does not. Some stepping-around debugging, it seems that this call (

llvm-project/llvm/tools/llvm-objdump/ELFDump.cpp

Line 350 in a2fb705

for (const RelocationRef &Reloc : Section.relocations()) {

) produces a zero-length sequence, when there are relocations in the section. (I verified this by using objcopy to preserve the minimal sections (--only-section=.relr.dyn --only-section=.dynamic --only-section=.dynstr), dumping them (llvm-objdump -R v llvm-readelf -r) and readelf dumps things, objdump does not - debugged into llvm-objdump to reach the above conclusion)

[llvmbot]

@llvm/issue-subscribers-tools-llvm-objdump

Author: David Blaikie (dwblaikie)

Seems llvm-readobj does support dumping relr relocations, but llvm-objdump does not. Some stepping-around debugging, it seems that this call ( https://github.com/llvm/llvm-project/blob/a2fb70523ac310af6d8a4d9663dfe7c9cd370c53/llvm/tools/llvm-objdump/ELFDump.cpp#L350 ) produces a zero-length sequence, when there are relocations in the section. (I verified this by using objcopy to preserve the minimal sections (--only-section=.relr.dyn --only-section=.dynamic --only-section=.dynstr), dumping them (llvm-objdump -R v llvm-readelf -r) and readelf dumps things, objdump does not - debugged into llvm-objdump to reach the above conclusion)

[chestnykh]

I looked at this a little bit and noticed that sh_link field of .relr.dyn contains zero unlike other sections which contain number of .dynsym in sh_link.

  [ 5] .dynsym           DYNSYM          00000000000003f0 0003f0 0000a8 18   A  6   1  8
  [ 6] .dynstr           STRTAB          0000000000000498 000498 00009f 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          0000000000000538 000538 00000e 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0000000000000548 000548 000040 00   A  6   1  8
  [ 9] .rela.dyn         RELA            0000000000000588 000588 000078 18   A  **5**   0  8
  [10] .rela.plt         RELA            0000000000000600 000600 000018 18  AI  **5**  24  8
  [11] .relr.dyn         RELR            0000000000000618 000618 000018 08   A  **0**   0  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4

@MaskRay could you please explain why sh_link of .relr.dyn is 0 instead of .dynsym number?

[chestnykh]

From elf standard :

I assume that the standard was written when SHT_RELR didnt exist yet so probably now .relr.dyn sh_link field should also contain shdr index of dynamic symbol table

[chestnykh]

CC: @jh7370

[jh7370]

Yes, SHT_RELR is a newer section type that has been adopted into the ELF gABI. You can find various information about it by searching online (e.g. https://groups.google.com/g/generic-abi/c/bX460iggiKg). That being said, such sections are intended for RELATIVE relocations which don't reference a symbol. I'm not sure why therefore it would need to reference a dynamic symbol table in the section header.

Much more likely the issue is simply that RELR support for llvm-objdump was simply never fully added/tested.

@dwblaikie, when you are asking for dumping RELR relocations, are you referring to just listing all such relocations, or specifically the inline-in-disassembly style that llvm-objdump -r -d would produce?

[MaskRay]

I looked at this a little bit and noticed that sh_link field of .relr.dyn contains zero unlike other sections which contain number of .dynsym in sh_link.

  [ 5] .dynsym           DYNSYM          00000000000003f0 0003f0 0000a8 18   A  6   1  8
  [ 6] .dynstr           STRTAB          0000000000000498 000498 00009f 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          0000000000000538 000538 00000e 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0000000000000548 000548 000040 00   A  6   1  8
  [ 9] .rela.dyn         RELA            0000000000000588 000588 000078 18   A  **5**   0  8
  [10] .rela.plt         RELA            0000000000000600 000600 000018 18  AI  **5**  24  8
  [11] .relr.dyn         RELR            0000000000000618 000618 000018 08   A  **0**   0  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4

@MaskRay could you please explain why sh_link of .relr.dyn is 0 instead of .dynsym number?

sh_link=0 is expected for .relr.dyn. .rela.dyn's sh_link member points to a symbol table section so that its relocations is meaningful when referencing symbols.
R_*_RELATIVE relocations do not reference a symbol, and the sh_link member can be zero.

[dwblaikie]

Yes, SHT_RELR is a newer section type that has been adopted into the ELF gABI. You can find various information about it by searching online (e.g. https://groups.google.com/g/generic-abi/c/bX460iggiKg). That being said, such sections are intended for RELATIVE relocations which don't reference a symbol. I'm not sure why therefore it would need to reference a dynamic symbol table in the section header.

Much more likely the issue is simply that RELR support for llvm-objdump was simply never fully added/tested.

@dwblaikie, when you are asking for dumping RELR relocations, are you referring to just listing all such relocations, or specifically the inline-in-disassembly style that llvm-objdump -r -d would produce?

The particular use case @chandlerc tripped over was just llvm-objdump -R, I believe. He's been measuring dynamic relocations in binaries (see some of the recent string table/string offset patches), trying to reduce the number to improve program startup time. Mostly just a symbol name is enough to figure out why the relocation is there and where to look/what to change to avoid it, if possible - I don't think having it applied/annotated in disassembly was necessary for this work.

[chandlerc]

@dwblaikie, when you are asking for dumping RELR relocations, are you referring to just listing all such relocations, or specifically the inline-in-disassembly style that llvm-objdump -r -d would produce?

The particular use case @chandlerc tripped over was just llvm-objdump -R, I believe. He's been measuring dynamic relocations in binaries (see some of the recent string table/string offset patches), trying to reduce the number to improve program startup time. Mostly just a symbol name is enough to figure out why the relocation is there and where to look/what to change to avoid it, if possible - I don't think having it applied/annotated in disassembly was necessary for this work.

To be clear, llvm-objdump -R doesn't show any symbol name -- I'm separately dumping the symbol names in .data.rel.ro and then using the address range from the start af that symbol to the start of the next to associate (non-RELR) dynamic relocations to the data structure symbol which they occur within.

All llvm-objdump -R prints in the metadata starting with the address at which the relocation is applied. That's enough for this approach.

However, the analogous llvm-readelf command seems to print information in a different format for RELR, highlighhting the fundamentally different structure of that relocation. I've not looked at how hard or easy it would be to port the analysis I'm doing over to that output format.

To an extent, I'm not worried about what format or what is printed. The more surprising thing is to silently omit them -- it gives the impression of there not being any relocations when there are.