link 9. position independent code filebasedon "self-servicelinux:...

Link 9. Position Independent Code

Young W. Lim

2018-12-10 Mon

Young W. Lim Link 9. Position Independent Code 2018-12-10 Mon 1 / 41

Outline

1 Linking - 9. Position Independent CodeBased onPosition Independent CodePIC Data ReferencesPIC Function CallsGOT example


Based on

"Self-service Linux: Mastering the Art of Problem Determination",Mark Wilding"Computer Architecture: A Programmer’s Perspective",Bryant & O’Hallaron

I, the copyright holder of this work, hereby publish it under the following licenses: GNU head Permission is granted tocopy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts,and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

CC BY SA This file is licensed under the Creative Commons Attribution ShareAlike 3.0 Unported License. In short:you are free to share and make derivative works of the file under the conditions that you appropriately attribute it,and that you distribute it only under a license compatible with this one.


Position Independent Code

1 Sharing the same library code in memory


Sharing the same library code in memory

library code can be loaded and executedat any address without modification by the linkerno a priori dedicated portion of the address space-fPIC in gcc


Sharing codes on IA32 system

calls to procedures in the same object

no relocationPC-relaive with know offsetsalready PIC

calls to externally defined proceduresreferences to global variables

need relocation at link timenormally not PIC


PIC Data References

1 Accessing global variables2 Global Offset Table (GOT)3 Indirect reference through the GOT4 Global variable access using the GOT


Accessing global variables (1)

PIC references to global variablesutilize the follwing fact

the data segment is always allocated immediatelyafter the code segmentregardless of the memory location wherean object module or a shared library is located

+--------------------+------------------+-----------------------+| Read/Write segment | higher addresses | .data, .bss |+--------------------+------------------+-----------------------+| Read-only segment | lower addresses | .text, .init, .rodata |+--------------------+------------------+-----------------------+starting from 0x08048000


Accessing global variables (2)

the distance betweenany instruction in the code segment andany variable inthe data segment

is a run-time constant

independent of the absolute memory locationsof code and data segments

Global Offset Table (GOT)at the beginning of .data segment.data follows .text segment


Global Offset Table (GOT)

each global data object (a global variable or function name)has an entry in the GOT which has a relocation recordat load time, the dynamic linker relocateseach entry in the GOT (of a global object)each entry contains the appropriate absolute addresseach object module that references global datahas its own GOT


Indirect reference through the GOT

at run time, each global variable isreferenced indirectly through the GOTPIC code incurs performance degradation

each global variable reference require 5 instructionsadditional memory reference to the GOTmachines with large register files can overcome this disadvantageson register demanding IA32 systems, losing even one registercan cause to spill the registers to the stack


Indirect reference - a pattern of codes

call LLLL: popl %ebx; # ebx contains the current PC

addl $VAROFF, %ebx # ebx points to the GOT entry for varmovl (%ebx), %eax # references indirect through the GOTmovl (%eax), %eax


addl $VAROFF, %ebx # ebx points to the GOT entry for varmovl (%ebx), %eax # references indirect through the GOTmovl (%eax), %eax


Global variable access using the GOT (1)


the call to LL pushes the return address on the stackthe return address is the address of popl instructionthen popl instruction pops this address LL into %ebx

the result of these 2 instructionsto move the value of the PC into register %ebxthe LL address

the return addressthe address of popl instructionthe current PC


Global variable access using the GOT (2)

addl $VAROFF, %ebx # ebx points to the GOT entry for varmovl (%ebx), %eax # fetch the absolute address to %eaxmovl (%eax), %eax # fetch the global variable

addl adds a constant offest $VAROFF to %ebxfor the appropriate entry in the GOTwhere the absolute address can be fetchednow, the global variable can be accessed indirectlythrough the GOT entry contained in %ebx

the 2 movl load the contents of the global variableindirectly through the GOD into register %eax


PIC Function Calls

1 Resolving external procedure calls2 Lazy Binding3 Vector addition and multiplication examples4 The Global Offset Table for the previous examples5 The Global Offset Table Example6 Procedure Linkage Table7 Procedure Linkage Table for the previous examples8 GOT and PLT for addvec9 Procedure Linkage Table Example


Resolving external procedure calls

the same approach to the PIC references to global variables

this approach require 3 additional instructions

ELF compilation systems use lazy binding techniquedefers the binding of procedure addressesuntil the first time the procedure is actually calledsignificant run-time overhead the first time callfor subsequent calls

one additional instructiona memory reference for the indirection


addl $PROCOFF, %ebx # ebx points to the GOT entry for proccall *(%ebx) # call indirect through the GOT


Lazy Binding

implemented with a comapact butsomewhat complex interactionbetween 2 data structures

GOT (Global Offset Table)PLT (Procedure Linkage Table)

if an object module calls any functionsthat are defined in shared librariesthen it has its own GOT and PLTGOT in .data sectionPLT in .text section


Vector addition and multiplication examples (1)

void addvec (int *x, int *y, int *z, int n){

int i;

for (i=0; i<n; i++)z[i] = x[i] + y[i];

}

void multvect (int *x, int *y, int *z, int n){

int i;

for (i=0; i<n; i++)z[i] = x[i] * y[i];

}


Vector addition and multiplication examples (2)

#include <stdio.h>#include "vector.h"

int x[2] = {1, 2};int y[2] = {3, 4};int z[2];

int main (){

addvec(x, y, z, 2);printf("z= (%d %d)\n", z[0], z[1]);return 0;

}


The Global Offset Table for the previous examples

Address Entry Contents Description08049674 GOT[ 0] 0804969c address of .dynamic section08049678 GOT[ 1] 4000a9f8 identifying info for the linker0804967c GOT[ 2] 4000596f entry point in dynamic linker08049680 GOT[ 3] 0804845c address of p̃ushl̃in PLT[ 1] (printf)08049684 GOT[ 4] 0804846a address of p̃ushl̃in PLT[ 2] (addvec)


The Global Offset Table Example (1)

| 08049674 | GOT[ 0] | 0804969c | address of .dynamic section |contains the address of the .dynamic seqmentdynamic linker use this address to bind procedure addressessuch as the location of the symbol table and relocation information

| 08049678 | GOT[ 1] | 4000a9f8 | identifying info for the linker |contains information that defines the module

| 0804967c | GOT[ 2] | 4000596f | entry point in dynamic linker |contains an entry point into the lazy binding code of the dynamic linker


The Global Offset Table Example (2)

each procedurethat is defined in a shared objectand called by main2.o gets an entry in the GOT

starting from GOT[ 3]GOT entries for printf defined in libc.so

-Got entries for addvec defined in libvector.so

| 08049680 | GOT[ 3] | 0804845c | address of pushl in PLT[ 1](printf) |

| 08049684 | GOT[ 4] | 0804846a | address of pushl in PLT[ 2](addvec) |


Procedure Linkage Table

PLT[ 0] : a special entry that jumps into dynamic linkereach called procedure has an entry in the PLTstarting at PLT[ 1]PLT[ 1] : printfPLT[ 2] : addvecinitially, after the program has been dynamically linked beginsexecutingprocedure printf and addvec are bound to the first instructionin their respective PLT entries


Procedure Linkage Table for the previous examples

PLT[0]08048444: pushl 0x8049678 # push &GOT[1]804844a: jmp *0x804967c # jmp to *GOT[2] (linker)8048450: # padding8048452: # padding

PLT[1] <printf>8048454: jmp *0x8049680 # jmp to *GOT[3]804845a: pushl $0x0 # ID for printf804845f: jmp 0x8048444 # jmp to PLT[0]

PLT[2] <addvec>8048464: jmp *0x8049684 # jmp to *GOT[4]804846a: pushl $0x8 # ID for addvec804846f: jmp 0x8048444 # jmp to PLT[0]


GOT and PLT for addvec (1)

+----------+---------+----------+----------------------------------------+| Address | Entry | Contents | Description |+----------+---------+----------+----------------------------------------+| 08049674 | GOT[ 0] | 0804969c | address of .dynamic section || 08049678 | GOT[ 1] | 4000a9f8 | identifying info for the linker || 0804967c | GOT[ 2] | 4000596f | entry point in dynamic linker || 08049680 | GOT[ 3] | 0804845c | address of pushl in PLT[ 1] (printf) || 08049684 | GOT[ 4] | 0804846a | address of pushl in PLT[ 2] (addvec) |+----------+---------+----------+----------------------------------------+

PLT[0]08048444: pushl 0x8049678 # push &GOT[1]804844a: jmp *0x804967c # jmp to *GOT[2] (linker)8048450: # padding8048452: # padding

... ... ... ...

PLT[2] <addvec>8048464: jmp *0x8049684 # jmp to *GOT[4]804846a: pushl $0x8 # ID for addvec804846f: jmp 0x8048444 # jmp to PLT[0]


GOT and PLT for addvec (2)

| 08049674 | GOT[ 0] | 0804969c | address of .dynamic section || 08049684 | GOT[ 4] | 0804846a | address of pushl in PLT[ 2](addvec) |8048464: jmp *0x8049684 # jmp to *GOT[ 4]804846a: pushl $0x8 # ID for addvec804846f: jmp 0x8048444 # jmp to PLT[ 0]


Procedure Linkage Table Example (1)

the call to addvec has the following form80485bb: e8 a4 fe ff ff call 8048464 <addvec>

at the first call, control is passed to the 1st instructionin PLT[ 2] which does the indirect jump through GOT[ 4]initially, each GOT entry contains the address of the push1 entryin the corresponding PLT engtrythe indirect jump in the PLT simply transfers control backto the next instruction in PLT[ 2]

this instruction pushes an ID for the addvec symbol onto the stack


Procedure Linkage Table Example (2)

the last instruction jumps to PLT[ 0],which pushes another word of identifying informationon the stack from GOT[ 1],then, jumps into the dynamic linker indirectly through GOT[ 2].the dynamic linker uses the two stack entriesto determinethe location of addvec,overwrites GOT[ 4] with this addressand passes control to addvec

the only additional overhead from this point onis the memory reference for the indirect jump


GOT example

//======= got.c =====================extern int i;

void test(void){

i = 100;}

$ gcc -nostdlib -shared -fPIC -o got.so ./got.c$ objdump --disassemble ./got.so$ readelf --sections ./got.so$ readelf --relocs ./got.so

http://bottomupcs.sourceforge.net/csbu/x3824.htm


GOT example - disassembly of .text

objdump --disassemble got.so

got.so: file format elf64-x86-64

Disassembly of section .text:

00000000000002f0 <test>:2f0: 55 push %rbp2f1: 48 89 e5 mov %rsp,%rbp2f4: 48 8b 05 fd 0c 20 00 mov 0x200cfd(%rip),%rax # 200ff8 <i>2fb: c7 00 64 00 00 00 movl $0x64,(%rax)301: 90 nop302: 5d pop %rbp303: c3 retq


GOT example - sections (1)

There are 16 section headers, starting at offset 0x1358:

Section Headers:[Nr] Name Type Address Offset

Size EntSize Flags Link Info Align[ 0] NULL 0000000000000000 00000000

0000000000000000 0000000000000000 0 0 0[ 1] .note.gnu.build-i NOTE 00000000000001c8 000001c8

0000000000000024 0000000000000000 A 0 0 4[ 2] .gnu.hash GNU_HASH 00000000000001f0 000001f0

0000000000000034 0000000000000000 A 3 0 8[ 3] .dynsym DYNSYM 0000000000000228 00000228

0000000000000090 0000000000000018 A 4 1 8[ 4] .dynstr STRTAB 00000000000002b8 000002b8

0000000000000020 0000000000000000 A 0 0 1[ 5] .rela.dyn RELA 00000000000002d8 000002d8

0000000000000018 0000000000000018 A 3 0 8[ 6] .text PROGBITS 00000000000002f0 000002f0

0000000000000014 0000000000000000 AX 0 0 1[ 7] .eh_frame_hdr PROGBITS 0000000000000304 00000304

0000000000000014 0000000000000000 A 0 0 4



[ 8] .eh_frame PROGBITS 0000000000000318 000003180000000000000038 0000000000000000 A 0 0 8

[ 9] .dynamic DYNAMIC 0000000000200f18 00000f1800000000000000e0 0000000000000010 WA 4 0 8

[10] .got PROGBITS 0000000000200ff8 00000ff80000000000000008 0000000000000008 WA 0 0 8

[11] .got.plt PROGBITS 0000000000201000 000010000000000000000018 0000000000000008 WA 0 0 8

[12] .comment PROGBITS 0000000000000000 00001018000000000000002a 0000000000000001 MS 0 0 1

[13] .symtab SYMTAB 0000000000000000 000010480000000000000228 0000000000000018 14 18 8

[14] .strtab STRTAB 0000000000000000 000012700000000000000058 0000000000000000 0 0 1

[15] .shstrtab STRTAB 0000000000000000 000012c80000000000000090 0000000000000000 0 0 1

Key to Flags:W (write), A (alloc), X (execute), M (merge), S (strings), I (info),L (link order), O (extra OS processing required), G (group), T (TLS),C (compressed), x (unknown), o (OS specific), E (exclude),l (large), p (processor specific)



There are 16 section headers, starting at offset 0x1358:


Size EntSize Flags Link Info Align[ ] NULL

[ 1] .note.gnu.build-i NOTE 1c8 1c824 A 4

[ 2] .gnu.hash GNU_HASH 1f0 1f034 A 3 8

[ 3] .dynsym DYNSYM 228 22890 18 A 4 1 8

[ 4] .dynstr STRTAB 2b8 2b820 A 1

[ 5] .rela.dyn RELA 2d8 2d818 18 A 3 8

[ 6] .text PROGBITS 2f0 2f014 AX 1

[ 7] .eh_frame_hdr PROGBITS 304 30414 A 4



[ 8] .eh_frame PROGBITS 318 31838 A 8

[ 9] .dynamic DYNAMIC 2 f18 f18e0 10 WA 4 8

[1 ] .got PROGBITS 2 ff8 ff88 8 WA 8

[11] .got.plt PROGBITS 2 1000 118 8 WA 8

[12] .comment PROGBITS 1 182a 1 MS 1

[13] .symtab SYMTAB 1 48228 18 14 18 8

[14] .strtab STRTAB 127058 1

[15] .shstrtab STRTAB 12c890 1

Key to Flags:W (write), A (alloc), X (execute), M (merge), S (strings), I (info),L (link order), O (extra OS processing required), G (group), T (TLS),C (compressed), x (unknown), o (OS specific), E (exclude),l (large), p (processor specific)


GOT example - relocation

Relocation section ’.rela.dyn’ at offset 0x2d8 contains 1 entry:Offset Info Type Sym. Value Sym. Name + Addend

000000200ff8 000100000006 R_X86_64_GLOB_DAT 0000000000000000 i + 0

200ff8 100000006 R_X86_64_GLOB_DAT 0 i + 0


GOT example - disassembly of .text (bottomupcs)

$ objdump --disassemble ./got.so

./got.so: file format elf64-ia64-little

Disassembly of section .text:

0000000000000410 <test>:410: 0d 10 00 18 00 21 [MFI] mov r2=r12416: 00 00 00 02 00 c0 nop.f 0x041c: 81 09 00 90 addl r14=24,r1;;420: 0d 78 00 1c 18 10 [MFI] ld8 r15=[r14]426: 00 00 00 02 00 c0 nop.f 0x042c: 41 06 00 90 mov r14=100;;430: 11 00 38 1e 90 11 [MIB] st4 [r15]=r14436: c0 00 08 00 42 80 mov r12=r243c: 08 00 84 00 br.ret.sptk.many b0;;



GOT example - sections (1) (bottomupcs)

$ readelf --sections ./got.soThere are 17 section headers, starting at offset 0x640:


Size EntSize Flags Link Info Align[ 0] NULL 0000000000000000 00000000

0000000000000000 0000000000000000 0 0 0[ 1] .hash HASH 0000000000000120 00000120

00000000000000a0 0000000000000004 A 2 0 8[ 2] .dynsym DYNSYM 00000000000001c0 000001c0

00000000000001f8 0000000000000018 A 3 e 8[ 3] .dynstr STRTAB 00000000000003b8 000003b8

000000000000003f 0000000000000000 A 0 0 1[ 4] .rela.dyn RELA 00000000000003f8 000003f8

0000000000000018 0000000000000018 A 2 0 8[ 5] .text PROGBITS 0000000000000410 00000410

0000000000000030 0000000000000000 AX 0 0 16[ 6] .IA_64.unwind_inf PROGBITS 0000000000000440 00000440

0000000000000018 0000000000000000 A 0 0 8[ 7] .IA_64.unwind IA_64_UNWIND 0000000000000458 00000458

0000000000000018 0000000000000000 AL 5 5 8

http://bottomupcs.sourceforge.net/csbu/x3824.htmYoung W. Lim Link 9. Position Independent Code 2018-12-10 Mon 37 / 41

GOT example - sections (2) (bottomupcs)

[ 8] .data PROGBITS 0000000000010470 000004700000000000000000 0000000000000000 WA 0 0 1

[ 9] .dynamic DYNAMIC 0000000000010470 000004700000000000000100 0000000000000010 WA 3 0 8

[10] .got PROGBITS 0000000000010570 000005700000000000000020 0000000000000000 WAp 0 0 8

[11] .sbss NOBITS 0000000000010590 000005900000000000000000 0000000000000000 W 0 0 1

[12] .bss NOBITS 0000000000010590 000005900000000000000000 0000000000000000 WA 0 0 1

[13] .comment PROGBITS 0000000000000000 000005900000000000000026 0000000000000000 0 0 1

[14] .shstrtab STRTAB 0000000000000000 000005b6000000000000008a 0000000000000000 0 0 1

[15] .symtab SYMTAB 0000000000000000 00000a800000000000000258 0000000000000018 16 12 8

[16] .strtab STRTAB 0000000000000000 00000cd80000000000000045 0000000000000000 0 0 1

Key to Flags:W (write), A (alloc), X (execute), M (merge), S (strings)I (info), L (link order), G (group), x (unknown)O (extra OS processing required) o (OS specific), p (processor specific);

http://bottomupcs.sourceforge.net/csbu/x3824.htmYoung W. Lim Link 9. Position Independent Code 2018-12-10 Mon 38 / 41

GOT example (1)

a simple shared library which refers to an external symbol iWe do not know the address of this symbol at compile time,so we leave it for the dynamic linker to fix up at runtime.for a sharable code, must handle the casewhere other processes simultaneously access the code as well.On IA64 the register r1 is known as the global pointerand always points to where the .got section is loaded into memory.



GOT example (2)

in the readelf output, the .got section starts 0x10570 bytes pastwhere library was loaded into memory.Thus if the library were to be loaded into memoryat address 0x6000000000000000 the .got would be at0x6000000000010570,and register r1 would always point to this address.



GOT example (3)

in the disassembly output, we store the value 100into the memory address held in register r15.If we look back we can see that register 15 holdsthe value of the memory address stored in register 14.Going back one more step, we see we load this address is foundby adding a small number to register 1.The GOT is simply a big long list of entries,one for each external variable.This means that the GOT entry for the external variable i isstored 24 bytes (that is 3 64 bit addresses).



link 9. position independent code filebasedon "self-servicelinux:...

Documents