Re: Where is libc for the Hurd?

[Roland McGrath <frob@debian.org>]

> I am looking at the nfsd, but I am getting traps and failures in:
> 
> sleep -> mach_msg -> mach_msg_trap

Please be more specific.  Can you show us the gdb backtrace and so forth?
What does "traps and failures" mean exactly?  

> (where -> is read "calls").  I would like to look at the definition
> of these two routines.  I don't really intend to build libc, though I
> suppose I can if necessary.

It should not be necessary if you just want to read the source.  There is a
single libc source for all GNU systems, both Linux and Hurd.  The current
development can be found at http://sourceware.cygnus.com, but you probably
just want to get the debian source package of glibc that goes with the
binary package you are using.  If you get that source, and use the
glibc_dbg package (libc0.2_dbg? something like that) of binaries with
debugging symbols (it's huge, but downloading it still probably faster than
building glibc from source), then gdb should just be happy to show you the
libc source directly.  The *dbg packages install debugging libraries in
/lib/libc_debug (though the loaded segments of the binaries are identical
to the non-dbg packages, they just have the debugging symbols as well), so
you need to use LD_LIBRARY_PATH=/lib/libc_debug (or via set env in gdb)
when starting the programs you want to debug.  

All that said, it is unlikely that reading sleep and mach_msg will shed any
specific light on the problems you are seeing.  I certainly wouldn't
discourage you from reading the source, but for a problem with nfsd I'm
quite sure that looking for a bug in sleep is a red herring.