From 4a8d9effcadc2670b0add531ddec15fc82ec0ce0 Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Mon, 10 Apr 2006 17:54:23 +0000 Subject: [PATCH] Notes about pic, static linking, and debugging dynamic linking. --- docs/busybox.net/programming.html | 32 ++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/docs/busybox.net/programming.html b/docs/busybox.net/programming.html index 7afa53e27..1214e70f7 100644 --- a/docs/busybox.net/programming.html +++ b/docs/busybox.net/programming.html @@ -17,6 +17,7 @@
  • Encrypted Passwords
  • Fork and vfork
  • Short reads and writes
  • +
  • Memory used by relocatable code, PIC, and static linking.
  • Who are the BusyBox developers?
  • @@ -346,6 +347,35 @@ data comes in that can be merged into the same packet. (In case you were wondering why action games that use TCP/IP set TCP_NODELAY to lower the latency on their their sockets, now you know.)

    +

    Memory used by relocatable code, PIC, and static linking.

    + +

    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 (ld-linux.so.2 or ld-uClibc.so.0) +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.

    + +

    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.

    + +

    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.

    + +

    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.

    +

    Who are the BusyBox developers?

    The following login accounts currently exist on busybox.net. (I.E. these @@ -375,7 +405,6 @@ solar :Ned Ludd timr :Tim Riker tobiasa :Tobias Anderberg vapier :Mike Frysinger -vodz :Vladimir N. Oleynik

    The following accounts used to exist on busybox.net, but don't anymore so @@ -395,6 +424,7 @@ miles proski rjune tausq +vodz :Vladimir N. Oleynik