diff options
Diffstat (limited to 'hurd/debugging')
| -rw-r--r-- | hurd/debugging/glibc.mdwn | 59 | ||||
| -rw-r--r-- | hurd/debugging/subhurd.mdwn | 91 |
2 files changed, 150 insertions, 0 deletions
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 |