swift 05/06/09 07:02:08 Modified: xml/htdocs/doc/en/handbook/draft pax-utils.xml Log: Some updates given by the pax author
Revision Changes Path 1.5 +10 -18 xml/htdocs/doc/en/handbook/draft/pax-utils.xml file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/pax-utils.xml?rev=1.5&content-type=text/x-cvsweb-markup&cvsroot=gentoo plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/pax-utils.xml?rev=1.5&content-type=text/plain&cvsroot=gentoo diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/handbook/draft/pax-utils.xml.diff?r1=1.4&r2=1.5&cvsroot=gentoo Index: pax-utils.xml =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/pax-utils.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- pax-utils.xml 9 Jun 2005 02:40:47 -0000 1.4 +++ pax-utils.xml 9 Jun 2005 07:02:08 -0000 1.5 @@ -1,6 +1,6 @@ <?xml version='1.0' encoding="UTF-8"?> -<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/pax-utils.xml,v 1.4 2005/06/09 02:40:47 vapier Exp $ --> +<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/draft/pax-utils.xml,v 1.5 2005/06/09 07:02:08 swift Exp $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> @@ -94,7 +94,7 @@ The <e>Program Header</e> informs the system how to create a process from the binary file. It is actually a table consisting of entries for each segment in the program. Each entry contains the type, addresses (physical - and virtual), size, ... + and virtual), size, access rights, ... </li> <li> The <e>Section Header</e> is a table consisting of entries for each section @@ -134,33 +134,25 @@ <p> An application that is dynamically linked to a shared object contains -<e>symbols</e>, substitutes for the real functionality. When such an application +<e>symbols</e>, references for the real functionality. When such an application is loaded in memory, it will first ask the runtime linker to resolve each and every symbol it has. The runtime linker will load the appropriate shared objects -in memory and return their location to the application. +in memory and resolve the symbolic references between them. </p> </body> </section> <section> -<title>Segments</title> +<title>Segments and Sections</title> <body> <p> -An application (or shared object) has several predefined segments. Summing them -all up is beyond the scope of this document, but a few do need to be mentioned -as they are used further in this guide: +How the ELF file is looked upon depends on the view we have: when we are dealing +with a binary file in Execution View, the ELF file contains segments. When +the file is seen in Linking View, the ELF file contains sections. +One segment spans just one or more (continuous) sections. </p> -<ul> - <li>The <c>text</c> segment contains executable code</li> - <li>The <c>data</c> segment contains program data</li> - <li> - The <c>dynamic</c> segment contains information relevant to dynamic - linking - </li> -</ul> - </body> </section> </chapter> @@ -398,7 +390,7 @@ </p> <p> -If you do not want text relocations to be possible, you will need to make sure +If you want to eliminate text relocations, you will need to make sure that the application and shared object is built with <e>Position Independent Code</e> (PIC), making references obsolete. This not only increases security, but also increases the performance in case of shared objects (allowing writes in -- [email protected] mailing list
