CODEWITHSUNDEEP
linkershared-librarieselfrelocation
ledonter
ledonter

Reputation: 1699

Why is .rela.plt necessary for resolving PIC function addresses?

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.

Upvotes: 3

Views: 514

Answers (1)

Daniel Walker
Daniel Walker

Reputation: 6740

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.

Upvotes: -1

Related Questions