Why trampoline from PLT to GOT instead of directly jumping to GOT?

1.2k Views Asked by At

I'm studying how the GOT and PLT are used in dynamic linking. I'm confused about why each dynamically linked function call seems to jump to a position in the PLT which will always jump to the same position in the GOT. Why not just jump to that position in the GOT in the first place? Why is another layer of indirection necessary?


I probably fundamentally misunderstand something about the GOT and PLT, so here's a brief description of my conceptual understanding of how the PLT and GOT are used.

We have a function called FunctionX, a corresponding position in the PLT called PLT[X], and a corresponding position in the GOT called GOT[X]. The address of the PLT and GOT are known at compile time but the address of FunctionX is not.

In order to call FunctionX:

1) Call (in the assembly sense) address of PLT[X].

2) PLT[X] is a jump to the value contained by GOT[X].

3a) If FunctionX was already resolved, GOT[X] contains the function address so step 2 is a jump to FunctionX.

3b) Otherwise, GOT[X] contains the address of code that will resolve the address of FunctionX at runtime, write that address into GOT[X], and jump to FunctionX. In this case, step 2 causes FunctionX to be resolved and then jumped to.

What is the purpose of step 1?

My understanding of this topic is sketchy so please point out any clarifications that could help the question.

1

There are 1 best solutions below

8
On

Just something to think about

Imagine the first call of whatever address is at GOT[X] from some client code (for example main). As you said in 3b) this will call the code that will resolve the address of FunctionX. But how can the resolving code know that you want to resolve FunctionX? You are calling it like a normal function, you do not provide any additional information for the resolver that it is FunctionX address you want to patch. Stub pushes on stack extra information before jumping to GOT[X].

Last few paragraphs of this article helped a lot.