1# Position independent code 2 3## i386 4 5Normal i386 PIC PLT entries look like this: `somefunc@plt: jmp 6*somefunc_pltgot_index(%ebx) somefunc_slow_path: push $somefunc_pltgot_index jmp 7zeroth_plt_entry 8` This fits neatly into 16 bytes. 9 10Under NaCl this takes up 64 bytes: `somefunc@plt: movl 11somefunc_pltgot_index(%ebx), %ecx andl %ecx, NACLMASK jmp *%ecx hlt; hlt; ... // 12pad to 32 bytes somefunc_slow_path: push $somefunc_pltgot_index jmp 13zeroth_plt_entry hlt; hlt; ... // pad to 32 bytes 14` See [issue 230](http://code.google.com/p/nativeclient/issues/detail?id=230) 15for an idea about how to make this smaller. 16 17## ARM 18 19Normal ARM PLT entries look like this: `somefunc@plt: add ip, pc, #0x0XX00000 20add ip, ip, #0x000YY000 ldr pc, [ip, #0xZZZ]! 21` This is the same for PIC and non-PIC code. This leaves the address of the GOT 22entry in `ip`, so there is no need for a separate slow-path code sequence for 23filling out the GOT entry address. The displacement of the GOT entry from the 24PLT entry is 0x0XXYYZZZ, so the maximum displacement is 256MB. 25 26Under NaCl this would become something like this: `somefunc@plt: add ip, 27pc, #0x0XX00000 add ip, ip, #0x000YY000 ldr %r7, [ip, #0xZZZ]! // Assuming no 28read sandboxing bic pc, %r7, #NACL_ARM_MASK 29` (or whatever register is typically used for this, probably not %r7 (on Google 30Code)) 31 32Or if the GOT and PLT are more than 256MB apart, it would have to become: 33`somefunc@plt: add ip, pc, #0xWW000000 add ip, ip, #0x00XX0000 add ip, 34ip, #0x0000YY00 ldr %r7, [ip, #0xZZ]! // Assuming no read sandboxing bic pc, 35%r7, #NACL_ARM_MASK nop nop nop 36` 37