3

While exploring ELF structure, I see this (this is objdump -d and readelf -r of the binary linked with a PIC .so containing ml_func):

0000000000400480 <_Z7ml_funcii@plt>:
  400480:       ff 25 92 0b 20 00       jmpq   *0x200b92(%rip)        # 601018 <_Z7ml_funcii>

Relocation section '.rela.plt' at offset 0x438 contains 1 entry:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000601018  000100000007 R_X86_64_JUMP_SLO 0000000000000000 _Z7ml_funcii + 0

Isn't .rela.plt redundant? It seems to store the same offset 601018 which is already calculated at ml_func@plt.

Or is it useful for some more complex cases like different relocation types? Or is it just an optimization of some sort (like, I guess it might be not trivial to get the 601018 from outside the ml_func@plt...)?..

I guess this question is similar to Why does the linker generate seemingly useless relocations in .rela.plt?, where they write that

.rela.plt is used to resolve function addresses, even during lazy linking.

I guess I wonder why the resolver couldn't do its work without the .rela.plt.

Daniel Walker
  • 6,380
  • 5
  • 22
  • 45
deshalder
  • 507
  • 2
  • 13
  • 1
    I don't know the answer off the top of my head but I'm pretty sure it's one of these: (1) The information is not redundant in the `.o` file, objdump is helpfully pulling it out of the relocation section and annotatating the disassembly with it. (2) The assembler has speculatively set up the jump to go to its best guess of the destination. If that guess is correct, the dynamic linker won't have to dirty as many pages. (3) The information is stored twice in the `.o` file for backward compatibilty with old static and/or dynamic linkers that don't understand `.rela.plt`. – zwol Jun 10 '22 at 02:37

1 Answers1

-1

The 601018 you see in .plt is not actually coming from that section. This is merely a helpful annotation which readelf is providing to you. readelf itself discovered this information by looking at .rela.plt.

When your program starts up, the global offset table (GOT) needs to contain an address inside the procedure linkage table (PLT) in order to bootstrap the dynamic linking logic. However, when your program is compiled, the compiler doesn't know yet know the absolute address of the PLT. That's why the .rela.plt section exists. The dynamic linker uses this information to patch the GOT when your program starts.

Daniel Walker
  • 6,380
  • 5
  • 22
  • 45