none

1 files changed, 36 insertions, 0 deletions

diff --git a/Hurd/DebuggingGlibc.mdwn b/Hurd/DebuggingGlibc.mdwn
new file mode 100644
index 00000000..71573b0b
--- /dev/null
+++ b/Hurd/DebuggingGlibc.mdwn
@@ -0,0 +1,36 @@
+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 involves at one point that the newly created libraries and loader actually work. (Unless you are cross-building, of course). 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.
+
+----
+
+Make sure static linking is working ok at all. The _elf/sln_ program in the glibc build ought to test that.
+
+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. Then debug its startup as a normal program on your working hurd, i.e. just run it with _--help_. Then try its full server startup, i.e. _settrans -a_.
+
+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.
+
+----
+
+Test it in a subhurd.
+
+----
+
+Test it on a real system.
+
+----
+
+Sources:
+
+* <http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00038.html>
+* [[ThomasSchwinge]]'s mind