@@ -, +, @@ relocation - In general they are. But IRELATIVE relocations are sorted to come last, and PLT entries are not sorted accordingly. --- sysdeps/linux-gnu/x86/arch.h | 11 +++++ sysdeps/linux-gnu/x86/plt.c | 101 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 111 insertions(+), 1 deletions(-) --- a/sysdeps/linux-gnu/x86/arch.h +++ a/sysdeps/linux-gnu/x86/arch.h @@ -19,6 +19,10 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA * 02110-1301 USA */ +#ifndef LTRACE_X86_ARCH_H +#define LTRACE_X86_ARCH_H + +#include "vect.h" #define BREAKPOINT_VALUE {0xcc} #define BREAKPOINT_LENGTH 1 @@ -30,9 +34,16 @@ #define ARCH_HAVE_ADD_PLT_ENTRY +#define ARCH_HAVE_LTELF_DATA +struct arch_ltelf_data { + struct vect plt_map; +}; + #ifdef __x86_64__ #define LT_ELFCLASS ELFCLASS64 #define LT_ELF_MACHINE EM_X86_64 #endif #define LT_ELFCLASS2 ELFCLASS32 #define LT_ELF_MACHINE2 EM_386 + +#endif /* LTRACE_X86_ARCH_H */ --- a/sysdeps/linux-gnu/x86/plt.c +++ a/sysdeps/linux-gnu/x86/plt.c @@ -27,10 +27,19 @@ #include "library.h" #include "trace.h" +static GElf_Addr +x86_plt_offset(uint32_t i) +{ + /* Skip the first PLT entry, which contains a stub to call the + * resolver. */ + return (i + 1) * 16; +} + GElf_Addr arch_plt_sym_val(struct ltelf *lte, size_t ndx, GElf_Rela *rela) { - return lte->plt_addr + (ndx + 1) * 16; + uint32_t i = *VECT_ELEMENT(<e->arch.plt_map, uint32_t, ndx); + return x86_plt_offset(i) + lte->plt_addr; } void * @@ -62,3 +71,93 @@ arch_elf_add_plt_entry(struct process *proc, struct ltelf *lte, return PLT_DEFAULT; } + +int +arch_elf_init(struct ltelf *lte, struct library *lib) +{ + VECT_INIT(<e->arch.plt_map, unsigned int); + + /* IRELATIVE slots may make the whole situation a fair deal + * more complex. On x86{,_64}, the PLT slots are not + * presented in the order of the corresponding relocations, + * but in the order it which these symbols are in the symbol + * table. That's static symbol table, which may be stripped + * off, not dynsym--that doesn't contain IFUNC symbols at all. + * So we have to decode each PLT entry to figure out what + * entry it corresponds to. We need to interpret the PLT + * table to figure this out. + * + * On i386, the PLT entry format is as follows: + * + * 8048300: ff 25 0c a0 04 08 jmp *0x804a00c + * 8048306: 68 20 00 00 00 push $0x20 + * 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x30> + * + * For PIE binaries it is the following: + * + * 410: ff a3 10 00 00 00 jmp *0x10(%ebx) + * 416: 68 00 00 00 00 push $0x0 + * 41b: e9 d0 ff ff ff jmp 3f0 <_init+0x30> + * + * On x86_64, it is: + * + * 400420: ff 25 f2 0b 20 00 jmpq *0x200bf2(%rip) # 601018 <_GLOBAL_OFFSET_TABLE_+0x18> + * 400426: 68 00 00 00 00 pushq $0x0 + * 40042b: e9 e0 ff ff ff jmpq 400410 <_init+0x18> + * + * On i386, the argument to push is an offset of relocation to + * use. The first PLT slot has an offset of 0x0, the second + * 0x8, etc. On x86_64, it's directly the index that we are + * looking for. + */ + + /* Here we scan the PLT table and initialize a map of + * relocation->slot number in lte->arch.plt_map. */ + + size_t i; + for (i = 0; i < vect_size(<e->plt_relocs); ++i) { + + GElf_Addr offset = x86_plt_offset(i); + uint32_t reloc_arg = 0; + + uint8_t byte; + if (elf_read_next_u8(lte->plt_data, &offset, &byte) < 0 + || byte != 0xff + || elf_read_next_u8(lte->plt_data, &offset, &byte) < 0 + || (byte != 0xa3 && byte != 0x25)) + goto next; + + /* Skip immediate argument in the instruction. */ + offset += 4; + + if (elf_read_next_u8(lte->plt_data, &offset, &byte) < 0 + || byte != 0x68 + || elf_read_next_u32(lte->plt_data, + &offset, &reloc_arg) < 0) { + reloc_arg = 0; + goto next; + } + + if (lte->ehdr.e_machine == EM_386) { + if (reloc_arg % 8 != 0) { + reloc_arg = 0; + goto next; + } + reloc_arg /= 8; + } + + next: + if (VECT_PUSHBACK(<e->arch.plt_map, &reloc_arg) < 0) { + arch_elf_destroy(lte); + return -1; + } + } + + return 0; +} + +void +arch_elf_destroy(struct ltelf *lte) +{ + VECT_DESTROY(<e->arch.plt_map, uint32_t, NULL, NULL); +} --