diff options
Diffstat (limited to 'xml/pic-guide.xml')
| -rw-r--r-- | xml/pic-guide.xml | 151 |
1 files changed, 151 insertions, 0 deletions
diff --git a/xml/pic-guide.xml b/xml/pic-guide.xml new file mode 100644 index 0000000..ce94b20 --- /dev/null +++ b/xml/pic-guide.xml @@ -0,0 +1,151 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> + +<guide link="/proj/en/hardened/pic-guide.xml" lang="en"> +<title>Introduction to Position Independent Code</title> + +<author title="Author"> + <mail link="solar@gentoo.org">solar</mail> +</author> +<author title="Editor"> + <mail link="pappy@gentoo.org">Alexander Gabert</mail> +</author> + +<abstract>What every developer should understand about using Position Independent Code</abstract> + +<!-- The content of this document is placed into the public domain, have fun --> +<license/> + +<version>1.2</version> +<date>2005-10-11</date> + +<chapter> +<title>Introduction to PIC - (Position Independent Code)</title> +<section> +<body> + +<p> +PIC code radically differs from conventional code in the way it +calls functions and operates on data variables.<br/> + +It will access these functions and data through an indirection table, +the "Global Offset Table" (GOT), by software convention accessible using +the reserved name "_GLOBAL_OFFSET_TABLE_".<br/> + +The exact mechanism used for this is hardware architecture dependent, +but usually a special machine register is reserved for setting up +the location of the GOT when entering a function.<br/> + +The rationale behind this indirect addressing is to generate code +that can be independently accessed of the actual load address.<br/> + +In a true PIC library without relocations in the text segment, +only the symbols exported in the "Global Offset Table" need updating +at run-time depending on the current load address of the various +shared libraries in the address space of the running process. +</p> + +<p> +Likewise, procedure calls to globally defined functions are redirected +through the "Procedure Linkage Table" (PLT) residing in the data segment +of the core image. Again, this is done to avoid run-time modifications +to the text segment. +</p> + +<p> +The linker-editor allocates the Global Offset Table and Procedure +Linkage Table when combining PIC object files into an image suitable for +mapping into the process address space. It also collects all symbols +that may be needed by the run-time link-editor and stores these along +with the image's text and data bits. Another reserved symbol, _DYNAMIC +is used to indicate the presence of the run-time linker structures. +Whenever _DYNAMIC is relocated to 0, there is no need to invoke the +run-time link- editor. If this symbol is non-zero, it points at a data +structure from which the location of the necessary relocation- and +symbol information can be derived. This is most notably used by the +start-up module, crt0, crt1S and more recently Scrt1. The _DYNAMIC +structure is conventionally located at the start of the data segment of +the image to which it pertains. +</p> + +<p> +On most architectures, when you compile source code to object code, you +need to specify whether the object code should be position independent +or not. There are occasional architectures which don't make the +distinction, usually because all object code is position independent by +virtue of the Application Binary Interface (ABI), or less often because +the load address of the object is fixed at compile time, which implies +that shared libraries are not supported by such a platform). + +If an object is compiled as position independent code (PIC), +then the operating system can load the object at any address +in preparation for execution. This involves a time overhead, +in replacing direct address references with relative addresses at +compile time, and a space overhead, in maintaining information to help +the runtime loader fill in the unresolved addresses at runtime. +Consequently, PIC objects are usually slightly larger and slower at +runtime than the equivalent non-PIC object. The advantage of sharing +library code on disk and in memory outweigh these problems as soon as +the PIC object code in shared libraries is reused. +</p> + +<p> +PIC compilation is exactly what is required for objects which will +become part of a shared library. Consequently, libtool builds PIC +objects for use in shared libraries and non-PIC objects for use in +static libraries. Whenever libtool instructs the compiler to generate a +PIC object, it also defines the preprocessor symbol, `PIC', so that +assembly code can be aware of whether it will reside in a PIC object or +not. +</p> + +<p> +Typically, as libtool is compiling sources, it will generate a `.lo' +object, as PIC, and a `.o' object, as non-PIC, and then it will use the +appropriate one of the pair when linking executables and libraries of +various sorts. On architectures where there is no distinction, the `.lo' +file is just a soft link to the `.o' file. +</p> + +<p> +In practice, you can link PIC objects into a static archive for a small +overhead in execution and load speed, and often you can similarly link +non-PIC objects into shared archives. +</p> + +<p> +When you use position-independent code, relocatable references are +generated as an indirection that use data in the shared object's data +segment. The text segment code remains read-only, and all relocation +updates are applied to corresponding entries within the data segment. +</p> + +<p> +If a shared object is built from code that is not position-independent, +the text segment will usually require a large number of relocations to +be performed at runtime. Although the runtime linker is equipped to +handle this, the system overhead this creates can cause serious +performance degradation. +</p> + +<p> +You can identify a shared object that requires relocations against its +text segment using tools such as 'readelf -d foo' and inspect the output +for any TEXTREL entry. The value of the TEXTREL entry is irrelevant. Its +presence in a shared object indicates that text relocations exist. +</p> + +<p> +References: +</p> +<ul> + <li><uri link="link.5.html">NetBSD link(5) File Formats Manual</uri></li> + <li><uri link="http://sources.redhat.com/autobook/autobook/autobook_71.html#SEC71">Autobook (Position Independent Code) from Chapter 10.2.1</uri></li> + <li><uri link="http://docs.sun.com/app/docs/doc/817-1984">docs.sun.com: Linker and Libraries Guide</uri></li> + <li>Linkers and Loaders <uri link="http://www.iecc.com/linker/linker08.html">chapter 8</uri> and <uri link="http://www.iecc.com/linker/linker10.html">chapter 10</uri></li> +</ul> + +</body> +</section> +</chapter> +</guide> |