diff options
| -rw-r--r-- | hurd/debugging/glibc.mdwn | 46 |
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/ [...] |