PPC plt handling 1. reference to foo@plt 2. load r11 with a .plt memory location that initially points to glink 3. branch -> glink -> __glink_PLTresolve -> _dl_runtime_resolve 4. this resolves so that the .plt memory location now points to foo 5. hereafter a foo@plt reference 6. loads r11 with the .plt memory location that is now the address of foo - there is one entry in .plt and glink for each symbol - the relocations are with respect to the .plt - the @plt code snippet entries are in the text section X86 plt handling 1. reference to foo@plt 2. indirect jump from contents of .got.plt to second instruction in foo@plt 3. push an id and branch _dl_runtime_resolve 4. this resolves so that .got.plt location now points to foo 5. hereafter a foo@plt reference 6. indirect jumps to the .got.plt memory location that is now the address of foo - the relocations are with respect to the .plt - the @plt code snippet entries are in the .plt section - .got.plt (_GLOBAL_OFFSET_TABLE_) somewhat analagous to ppc .plt stap .plt handling iterate_over_plt (currently only supports x86) runs through each entry in the .plt section, uses the relocations to find what symbol an entry is for and does a callback. For ppc this strategy will not work since for ppc the .plt contains only the address to be branched to, the plt code snippets are in the .text section. It would be necessary to scan the elf symbol table for the @plt entries
Comments from Petr Machata who added ppc plt support to ltrace: PPC PLT slots themselves are only used on first call, which means you never hit them on prelinked binary or often don't hit them when attaching to a running one. ltrace goes to great lengths to simulate the as-if behavior, meaning as-if ppc had sane PLT tables. It unprelinks stuff, singlestepping through the dynamic linker.
Detailed info on ppc plt support can be found in the top comments in the ltrace ppc plt source: tree/sysdeps/linux-gnu/ppc/plt.c