printf@plt
is actually a small stub which calls the real printf
function. This real function may be mapped into any location in a given virtual address space so, in order to allow proper code sharing of your own code (left side below), you don't want to apply the fixups to it directly since it too can be mapped anywhere in the virtual address space.plt
variant is a smaller process-specific area which isn't shared so a given process can change that however it wants to. Mapped to: 0x12345678 0x90000000 0x88888888 +-------------------------+ +----------+ +---------------------+ | | | Private | | |ProcA | | | PLT/GOT | | | | | | area | | | | | +----------+ | |========| Shared application code |==============| Shared library code |======== | | +----------+ | | | | | Private | | |ProcB | | | PLT/GOT | | | | | | area | | | +-------------------------+ +----------+ +---------------------+ Mapped to: 0x20202020 0x90000000 0x66666666
This is a simple case where the PLT maps to a known location. In your scenario, it appears to be located relative to the current program counter so it's probably a separate section following the shared application code.Example:<printf@plt+0>: jmpq *0x2004c2(%rip) # 0x600860 <_GLOBAL_OFFSET_TABLE_+24>
It's clearly using a program-counter-relative lookup to find the actual printf
function. That _GLOBAL_OFFSET_TABLE_
will hold fix-ups for as many functions as needed.printf@plt
(in the PLT) is a multi-stage operation, in which:printf@plt
in the PLT.printf
).printf@plt
in the PLT.printf
.联系客服