svn commit: trunk/busybox/docs/

landley at landley at
Mon Apr 10 17:54:24 UTC 2006

Author: landley
Date: 2006-04-10 10:54:23 -0700 (Mon, 10 Apr 2006)
New Revision: 14791

Notes about pic, static linking, and debugging dynamic linking.


Modified: trunk/busybox/docs/
--- trunk/busybox/docs/	2006-04-10 17:50:11 UTC (rev 14790)
+++ trunk/busybox/docs/	2006-04-10 17:54:23 UTC (rev 14791)
@@ -17,6 +17,7 @@
     <li><a href="#tips_encrypted_passwords">Encrypted Passwords</a></li>
     <li><a href="#tips_vfork">Fork and vfork</a></li>
     <li><a href="#tips_short_read">Short reads and writes</a></li>
+    <li><a href="#tips_memory">Memory used by relocatable code, PIC, and static linking.</a></li>
   <li><a href="#who">Who are the BusyBox developers?</a></li>
@@ -346,6 +347,35 @@
 wondering why action games that use TCP/IP set TCP_NODELAY to lower the latency
 on their their sockets, now you know.)</p>
+<h2><a name="tips_memory">Memory used by relocatable code, PIC, and static linking.</a></h2>
+<p>The downside of standard dynamic linking is that it results in self-modifying
+code.  Although each executable's pages are mmaped() into a process's address
+space from the executable file and are thus naturally shared between processes
+out of the page cache, the library loader ( or
+writes to these pages to supply addresses for relocatable symbols.  This
+dirties the pages, triggering copy-on-write allocation of new memory for each
+processes's dirtied pages.</p>
+<p>One solution to this is Position Independent Code (PIC), a way of linking
+a file so all the relocations are grouped together.  This dirties fewer
+pages (often just a single page) for each process's relocations.  The down
+side is this results in larger executables, which take up more space on disk
+(and a correspondingly larger space in memory).  But when many copies of the
+same program are running, PIC dynamic linking trades a larger disk footprint
+for a smaller memory footprint, by sharing more pages.</p>
+<p>A third solution is static linking.  A statically linked program has no
+relocations, and thus the entire executable is shared between all running
+instances.  This tends to have a significantly larger disk footprint, but
+on a system with only one or two executables, shared libraries aren't much
+of a win anyway.</p>
+<p>You can tell the glibc linker to display debugging information about its
+relocations with the environment variable "LD_DEBUG".  Try
+"LD_DEBUG=help /bin/true" for a list of commands.  Learning to interperet
+"LD_DEBUG=statistics cat /proc/self/statm" could be interesting.</p>
 <h2><a name="who">Who are the BusyBox developers?</a></h2>
 <p>The following login accounts currently exist on  (I.E. these
@@ -375,7 +405,6 @@
 timr      :Tim Riker
 tobiasa   :Tobias Anderberg
 vapier    :Mike Frysinger
-vodz      :Vladimir N. Oleynik
 <p>The following accounts used to exist on, but don't anymore so
@@ -395,6 +424,7 @@
+vodz      :Vladimir N. Oleynik

More information about the busybox-cvs mailing list