diff options
| author | Thomas Schwinge <tschwinge@gnu.org> | 2007-09-05 15:41:39 +0200 |
|---|---|---|
| committer | Thomas Schwinge <tschwinge@gnu.org> | 2007-09-05 15:41:39 +0200 |
| commit | 5e7dea36849cf832862a8d66cd0f01c7d4b8d126 (patch) | |
| tree | 117e6f430528d65c6ffe53ab2b245d7a28c43ae5 /hurd | |
| parent | a5804a989267906cf4c61278af8207a4947a1653 (diff) | |
Formatting.
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/debugging/glibc.mdwn | 38 |
1 files changed, 25 insertions, 13 deletions
diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn index 2fec3b9c..a0890fe8 100644 --- a/hurd/debugging/glibc.mdwn +++ b/hurd/debugging/glibc.mdwn @@ -1,26 +1,36 @@ -Here are some hints about how to approach testing after nontrivial changes to glibc have been done. +Here are some hints about how to approach testing after nontrivial changes to +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 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: [...] CPP='gcc -E -x c-header' [...]/build/elf/ld.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...] Segmentation fault ----- +--- -If building glibc succeeds, the next thing to try is running the test suite, or parts of it. +If building glibc succeeds, the next thing to try is running the test suite, or +parts of it. Here is a list of known failures: [TODO]. ----- +--- -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/_. +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/`. -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. +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. [TODO]. @@ -35,7 +45,9 @@ Then try its full server startup. $ cd node/ [...] -Make sure dynamic linking for servers is working. If you haven't broken the ABI, you can just use an existing _/hurd/foobar_ binary, started the way glibc's _testrun.sh_ does it. +Make sure dynamic linking for servers is working. If you haven't broken the +ABI, you can just use an existing `/hurd/foobar` binary, started the way +glibc's `testrun.sh` does it. [TODO]: Is this the correct way to do that? @@ -43,15 +55,15 @@ Make sure dynamic linking for servers is working. If you haven't broken the ABI, $ cd node/ [...] ----- +--- -Test it in a subhurd. See [[DebuggingViaSubhurds]]. +Test it in a [[subhurd]]. ----- +--- Test it on a real system. ----- +--- Sources: |