PIC information: what changed
Revision 2 to 3. Removed lines have a minus sign; added lines have a plus sign.
| Old | New | Line | |
|---|---|---|---|
| 1 | 1 | The linker/loader maintain a global offset table, which consists of an array of pointers to exported variables. All access to those variables is supposed to go through these pointers, if the variable could reside within another dynamic object. | |
| 2 | 2 | ||
| 3 | 3 | If 'variable' is an exported symbol, then 'variable@GOT' is replaced by the linker with a constant: the offset of the GOT slot containing the pointer to variable. So, if the %ebx register contains the start address of the GOT, you can retrieve this pointer via | |
| 4 | 4 | ||
| 5 | 5 | ``` asm | |
| 6 | 6 | movl variable@GOT(%ebx), %eax | |
| 7 | 7 | ``` | |
| 8 | 8 | ||
| 9 | 9 | If you want the value of the variable, you need another indirection: | |
| 10 | 10 | ||
| 11 | 11 | ``` asm | |
| 12 | 12 | movl (%eax), %eax | |
| 13 | 13 | ``` | |
| 14 | 14 | ||
| 15 | 15 | If you know, however, that the variable in question must reside in the same dynamic object as the user, then you can avoid that double indirection, by using the GOTOFF facility. 'variable@GOTOFF' is replaced by the linker with another constant: the difference between the absolute address of the variable and the address of the global offset table (of the current dynamic object). Thus, you can retrieve the value of the variable in one step using: | |
| 16 | 16 | ||
| 17 | 17 | ``` asm | |
| 18 | 18 | movl variable@GOTOFF(%ebx), %eax | |
| 19 | 19 | ``` | |
| 20 | 20 | ||
| 21 | 21 | ------------------------------------------------------------------------ | |
| 22 | 22 | ||
| 23 | 23 | **source unknown** | |
| 24 | 24 | ||
| 25 | - | ||
| 26 | - | ||
| 25 | + | ``` pascal | |
| 26 | + | From: Joerg Pommnitz (pommnitz@heidelbg.ibm.com) | |
| 27 | + | Subject: Re: ELF--Position-Independent Code: Why? | |
| 27 | 28 | ||
| 28 | - | ||
| 29 | - | ||
| 30 | - | ||
| 29 | + | View this article only | |
| 30 | + | Newsgroups: comp.os.linux.development.system | |
| 31 | + | Date: 1995/08/01 | |
| 31 | 32 | ||
| 32 | - | ||
| 33 | - | ||
| 34 | - | ||
| 35 | - | ||
| 36 | - | ||
| 37 | - | ||
| 38 | - | ||
| 39 | - | ||
| 33 | + | Just to add a small remark to this thread: | |
| 34 | + | It is NO requirement that ELF dynamic libraries are position independent. You | |
| 35 | + | can build dynamic libraries from plain, non-pic object files. The disadvantage | |
| 36 | + | of this is the fact that they are not shared very much. The ELF loader | |
| 37 | + | has to do relocations, so lots of pages become dirty and can't be shared | |
| 38 | + | among processes. That's why non-pic ELF dynamic libraries should not be used | |
| 39 | + | for code that's normally shared among lots of processes running at the same | |
| 40 | + | time (i.e. libc, libX11, ...). | |
| 40 | 41 | ||
| 41 | - | ||
| 42 | - | ||
| 42 | + | Best Regards | |
| 43 | + | Joerg | |
| 44 | + | ``` | |
| 43 | 45 | ||
| 44 | 46 | ------------------------------------------------------------------------ | |
| 45 | 47 | ||
| 46 | 48 | However pic code is also bulkier and slower, and specially by C++ code with its massive number of symbols this is a problem. This can be avoided by taking a large heap of libraries and relocate them as a kind of library cache. Most startup accelerators in commercial OSes work that way (OSX/Windows). | |
| 47 | 49 | ||
| 48 | 50 | Marcov 13:57, 20 March 2007 (CET) | |
| 49 | 51 | ||
| 50 | 52 | ### fpcmake | |
| 51 | 53 | ||
| 52 | 54 | fpcmake automatically adds -Cg/-fPIC for x86-64 platforms: | |
| 53 | 55 | ||
| 54 | 56 | - for freebsd, openbsd, netbsd, linux, solaris | |
| 55 | 57 | - for darwin -Cg is enabled by the compiler (see below) | |
| 56 | 58 | ||
| 57 | 59 | See [this thread](http://lists.freepascal.org/pipermail/fpc-pascal/2014-November/043159.html) for more details. | |
| 58 | 60 | ||
| 59 | 61 | ### fpc compiler | |
| 60 | 62 | ||
| 61 | 63 | PIC code is on by default for | |
| 62 | 64 | ||
| 63 | 65 | - for darwin, -Cg is always on by default on all (i386, x86-64, arm). Because it's also on by default in the system compilers (apple's gcc). Apple also requires any iOS code to be PIC (starting with iOS 7.0) | |
| 64 | 66 | ||
| 65 | 67 | For other platforms it's off by default, because system native compiler has it off by default as well. | |
| 66 | 68 | ||
| 67 | 69 | --- | |
| 68 | 70 | *From the Free Pascal wiki, page "PIC information", as it stood on 2014-11-19 after a change by Skalogryz, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 69 | 71 | Category: FPC internals |