Rearrange some pages about debugging and neighborhurds and subhurds.

5 files changed, 235 insertions, 6 deletions

diff --git a/hurd/debbuging.mdwn b/hurd/debugging.mdwn
index 20446b6e..da35d819 100644
--- a/hurd/debbuging.mdwn
+++ b/hurd/debugging.mdwn
@@ -15,7 +15,19 @@ your rights under copyright, including the rights to copy, modify, and
 redistribute your contributions.
 """]]
 
-See:
+# Strategies
 
-* [[NeighborHurd]]
-* [[NonInvasiveDebugging]]
+* [[subhurd]]
+* [[noninvasivedebugging]]
+
+# The GNU Debugger *GDB*
+
+* [Manual](http://sourceware.org/gdb/documentation/)
+* [Hurd-specific features](http://sourceware.org/gdb/current/onlinedocs/gdb_19.html#Hurd%20Native).
+* [[noninvasivedebugging]]
+* [When disassemble doesn't work](http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00039.html)
+
+
+# About Specific Packages
+
+* [[glibc]]
diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn
new file mode 100644
index 00000000..2fec3b9c
--- /dev/null
+++ b/hurd/debugging/glibc.mdwn
@@ -0,0 +1,59 @@
+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:
+
+    [...]
+    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.
+
+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 with cthreads is working. If you can get an _ext2fs.static_ compiled and linked against the new glibc, that is good.
+
+[TODO].
+
+Then debug its startup as a normal program on your working hurd.
+
+    $ [...]/ext2fs.static --help
+    [...]
+
+Then try its full server startup.
+
+    $ settrans -ca node [...]/ext2fs.static <BACKEND>
+    $ 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.
+
+[TODO]: Is this the correct way to do that?
+
+    $ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs <BACKEND>
+    $ cd node/
+    [...]
+
+----
+
+Test it in a subhurd. See [[DebuggingViaSubhurds]].
+
+----
+
+Test it on a real system.
+
+----
+
+Sources:
+
+* <http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00038.html>
+* [[Thomas_Schwinge|tschwinge]]'s mind
diff --git a/hurd/debugging/subhurd.mdwn b/hurd/debugging/subhurd.mdwn
new file mode 100644
index 00000000..6aa64e99
--- /dev/null
+++ b/hurd/debugging/subhurd.mdwn
@@ -0,0 +1,91 @@
+# General Information
+
+* [[/hurd/neighborhurd]]
+* [[/hurd/subhurd]]
+
+---
+
+# Debugging the Hurd Startup Process
+
+_one.full_ is the subhurd's root file system image and has been installed as
+follows: [TODO]
+
+_Wx_ translates to terminal window _x_.
+
+W1
+
+    $ fsysopts one.full/ --readonly
+    $ sudo boot -I -d -s -D one.full/ one.full/boot/script.boot one.full.ext2
+    Pausing. . .
+
+(In theory it shouldn't be neccessary to run the subhurd as user _root_, but in
+practice [that doesn't work at the
+moment](http://savannah.gnu.org/bugs/?17341).)
+
+W2
+
+    $ ps -Af
+    [...]
+        root   851   385  p4  0:00.01 boot -I -d -s -D one.full/ one.full/boot/script.boot one.full.ext2
+           -   853     1   ?  0:00.00 ?
+           -   854     1   ?  0:00.00 ?
+    [...]
+    $ sudo gdb /var/tmp/one.full/hurd/ext2fs.static
+    [...]
+    (gdb) attach 853
+    Attaching to program `/var/tmp/one.full/hurd/ext2fs.static', pid 853
+    warning: Can't modify tracing state for pid 853: No signal thread
+    Can't fetch registers from thread 1: No such thread
+
+(The _boot_ program [could be modified to print out the
+pids](http://savannah.gnu.org/bugs/?19254), so that one wouldn't have to fumble
+with _ps_.)
+
+W3
+
+    $ sudo gdb /var/tmp/one.full/lib/ld.so.1
+    [...]
+    (gdb) set solib-absolute-prefix /var/tmp/one.full
+    (gdb) attach 854
+    Attaching to program `/var/tmp/one.full/lib/ld.so.1', pid 854
+    warning: Can't modify tracing state for pid 854: No signal thread
+    Can't fetch registers from thread 1: No such thread
+
+W1
+
+    [<Enter>.]
+    /hurd/ext2fs.static --bootflags=-dsf --host-priv-port=38 --device-master-port=43 --exec-server-task=47 -Tdevice pseudo-root
+    /lib/ld.so.1 /hurd/exec
+
+Now that this step has been accomplished, you can set break points in GDB, etc.
+
+W2
+
+    (gdb) continue
+    Continuing.
+    warning: Can't wait for pid 853: No child processes
+
+W1
+
+    Hurd server bootstrap: ext2fs.static[pseudo-root] exec
+
+W3
+
+    (gdb) continue
+    Continuing.
+    warning: Can't wait for pid 854: No child processes
+
+    Program received signal EXC_BAD_ACCESS, Could not access memory.
+    __mach_port_mod_refs (task=1, name=139802, right=1, delta=-1)
+        at /var/tmp/glibc-2_5-branch/build_--without-tls_--without-__thread/mach/RPC_mach_port_mod_refs.c:132
+    132             InP->Head.msgh_reply_port = __mig_get_reply_port();
+    (gdb) x/i $pc
+    0x168f2 <__mach_port_mod_refs+82>:      call   0x151b0 <__mig_get_reply_port>
+
+---
+
+Sources:
+
+* <http://www.gnu.org/software/hurd/howto/subhurd.html>
+* <http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00030.html>
+* [[Thomas_Schwinge|tschwinge]]'s mind
diff --git a/hurd/neighborhurd.mdwn b/hurd/neighborhurd.mdwn
index b4d25586..76ae20d1 100644
--- a/hurd/neighborhurd.mdwn
+++ b/hurd/neighborhurd.mdwn
@@ -27,12 +27,13 @@ When extra hardware is not available, it is possible to
 use a sub-hurd.  A sub-Hurd is like a neighbor Hurd,
 however, makes use of some resources provided by another
 Hurd.  For instance, backing store and the console.
-([[SubhurdHowto]])
+([[subhurd]])
 
 Sub-hurds are extremely useful for debugging core
 servers as it is possible to attach to them with gdb
-from the parent ([[DebuggingViaSubhurds]].  This avoids
+from the parent ([[debugging_via_neighborhurds|debugging/neighborhurd]]).
+This avoids
 deadlock, e.g., when the instance of gdb stops the
 server but requires its use.
-(Note: it is possible to use [[NonInvasiveDebugging]],
+(Note: it is possible to use [[noninvasivedebugging]],
 but this is less flexible.)
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn
new file mode 100644
index 00000000..7cf2bb76
--- /dev/null
+++ b/hurd/subhurd.mdwn
@@ -0,0 +1,66 @@
+# <a name="Subhurd_Howto"> Subhurd Howto </a>
+
+One of the most visible goodies offered by the Hurd design, is the possibility to run neighbour Hurds AKA subhurds.
+
+Sadly, there is very little information available on using subhurds. This page tries to help getting you started.
+
+## <a name="Preparing"> Preparing </a>
+
+To run a subhurd, you need an additional partition with an installed Hurd system. In principle, you can also use your main partition in read-only mode; but this obviously will create severe limitations. Usually, you will want a complete independant system.
+
+The system for the subhurd is a normal Hurd installation, which could just as well run standalone. You can use any of the various possible installation methods, or reuse an existing installation if you already have several. If using Debian GNU/Hurd, the easiest is probably to use crosshurd, which you can run directly from your main Hurd to set up another Hurd on a different partition, without ever rebooting. (You can run the native-install step from a chroot or already in a subhurd.)
+
+## <a name="Booting"> Booting </a>
+
+To boot the subhurd, you need a boot script. For historical reasons, usually /boot/servers.boot is used. (Originally, this was also used to boot the main Hurd, using "serverboot". Nowadays, this isn't used for the main boot anymore, as GRUB can directly load all the necessary modules.)
+
+However, the canonical /boot/servers.boot file is no longer distributed with Debian GNU/Hurd. Here is a slightly adopted version:
+
+       # Boot script file for booting GNU Hurd.  Each line specifies a file to be
+       # loaded by the boot loader (the first word), and actions to be done with it.
+
+       # First, the bootstrap filesystem.  It needs several ports as arguments,
+       # as well as the user flags from the boot loader.
+       /hurd/ext2fs.static --bootflags=${boot-args} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -Tdevice ${root-device} $(task-create) $(task-resume)
+
+       # Now the exec server; to load the dynamically-linked exec server program,
+       # we have the boot loader in fact load and run ld.so, which in turn
+       # loads and runs /hurd/exec.  This task is created, and its task port saved
+       # in ${exec-task} to be passed to the fs above, but it is left suspended;
+       # the fs will resume the exec task once it is ready.
+       /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
+
+       ## default pager
+       #/dev/sd0b $(add-paging-file)
+
+(NOTE: It's very important not to introduce spurious line breaks, so be very careful when copying! All the options following ext2fs.static have to be on a single line.)
+
+Now actually booting the subhurd is a simple matter of issuing (as root):
+
+       boot servers.boot /dev/hd0s6
+
+(Replace hd0s6 by the name of your partition for the subhurd.)
+
+NOTE: The partition must be unmounted (or mounted read-only) before you boot from it!
+
+(In theory it shouldn't be neccessary to run the subhurd as user _root_, but in practice [that doesn't work at the moment](http://savannah.gnu.org/bugs/?17341).)
+
+Now the subhurd should boot just like a normal Hurd started directly from GRUB, finally presenting a login prompt. The boot program serves as proxy for the subhurd, so you can control it from the terminal where you issued the boot command.
+
+To exit the subhurd, issue halt or reboot. This should exit it cleanly, but for some reason it doesn't always work; sometimes it will output various errors and then hang. If that happens, you need to kill the subhurd processes manually from a different terminal.
+
+## <a name="Using"> Using </a>
+
+In the subhurd, you can do basically all the same things as in the main Hurd.
+
+You can even set up networking: Just invoke settrans on the /servers/socket/2 as usual inside the subhurd, only using a different local IP than in the main Hurd. This way, the subhurd will be able to communicate to the outside world with it's own IP -- allowing for example to do apt-get inside the subhurd, or to ssh directly into the subhurd.
+
+If you want to access the subhurd processes from the outside, e.g. for debugging purposes (or to get rid of a subhurd that didn't exit cleanly...), you need to find out how main Hurd PIDs correspond to subhurd processes: The subhurd processes appear in the main Hurd (e.g. if doing ps -e) as unknown processes, and vice versa, but the PIDs are different! To find out which process is which, you can simply compare the order -- while the numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using ps -l), as many servers have very characteristic thread counts.
+
+## <a name="Further_Info"> Further Info </a>
+
+On [[debugging/subhurd]] you can find information about how to use subhurd for debugging purposes.
+
+
+Roland's [tutorial](http://www.gnu.org/software/hurd/howto/subhurd.html)
+on setting up sub-hurds.