Incorporate <http://sourceware.org/ml/libc-alpha/2008-11/msg00031.html> and further improvements.

1 files changed, 32 insertions, 14 deletions

diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn
index f0fe8b61..54a3446c 100644
--- a/hurd/debugging/glibc.mdwn
+++ b/hurd/debugging/glibc.mdwn
@@ -13,11 +13,11 @@ glibc have been done.
 
 ---
 
-First step is having the build a glibc complete.  This is actually more
-difficult than one might expect, as it involves (towards the end of the build
-process; unless you are cross-building, of course), that the newly created
-libraries and loader actually work: they're used to run the `rpcgen`
-program.  If that step doesn't succeed, it'll look similar to this:
+First step is having the build of glibc succeed.  This is actually more
+difficult than one might expect as it involves (towards the end of the build
+process -- unless you are [[building/cross-compiling]], of course -- that the
+newly created libraries and loader actually work: they'll be used to run the
+`rpcgen` program.  If that step doesn't succeed, it'll look similar to this:
 
     [...]
     CPP='gcc -E -x c-header' [...]/build/elf/ld.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...]
@@ -25,8 +25,8 @@ program.  If that step doesn't succeed, it'll look similar to this:
 
 ---
 
-If building glibc succeeds, the next thing to try is running the test suite, or
-parts of it.
+Unless [[building/cross-compiling]], the next thing you'll probably want to do
+is running the test suite, or parts of it.
 
 Here is a list of known failures:
 
@@ -34,10 +34,28 @@ Here is a list of known failures:
 
 ---
 
-Make sure static linking is working OK at all.  The `elf/sln` program (a
-stripped-down `ln` that is statically linked) in the glibc build ought to test
-that.  Also, static linking under various conditions will already have been
-tested when running the test suite, especially in `elf/` and `dlfcn/`.
+If you've been doing simple changes to glibc functions that end up in
+`libc.so`, you may test them like this (like for a `strerror_l` implementation
+in this case):
+
+    $ LD_PRELOAD=./libc.so ./ld.so ./a.out 10 1073741928 de_DE.utf8
+    1073741928 (0x40000068): Computer bought the farm
+    1073741928 (0x40000068): Der Computer hat den Bauernhof erworben
+
+You usually will only have luck using the new `libc.so` (from
+`[glibc-build]/libc.so`) in combination together with the new `ld.so` (from
+`[glibc-build]/elf/ld.so`):
+
+    $ LD_PRELOAD=./libc.so ./a.out 10 1073741928 de_DE.utf8
+    Killed
+    $ LD_PRELOAD=./libc.so /lib/ld.so ./a.out 10 1073741928 de_DE.utf8
+    Killed
+
+Make sure static linking is working OK at all.  Running the
+`[glibc-build]/elf/sln` program (a stripped-down `ln` that is statically
+linked) ought to test that.  Also, static linking under various conditions will
+already have been tested when running the test suite, especially in `elf/` and
+`dlfcn/`.
 
 Make sure static linking with cthreads is working.  If you can get an
 `ext2fs.static` compiled and linked against the new glibc, that is good.
@@ -51,8 +69,8 @@ Then debug its startup as a normal program on your working hurd.
 
 Then try its full server startup.
 
-    $ settrans -ca node [...]/ext2fs.static <BACKEND>
-    $ cd node/
+    $ settrans -ca node [...]/ext2fs.static BACKING_STORE
+    $ ls -l node/
     [...]
 
 Make sure dynamic linking for servers is working.  If you haven't broken the
@@ -61,7 +79,7 @@ glibc's `testrun.sh` does it.
 
 [TODO]: Is this the correct way to do that?
 
-    $ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs <BACKEND>
+    $ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs BACKING_STORE
     $ cd node/
     [...]