On Fri, Feb 25, 2000 at 04:13:44PM -0500, Roland McGrath wrote:
I'm not so familiar with gdb aside from bt, print, break, step and cont.
Is there anyway to cause it to log the session to a file?
> The most useful thing you can do is try to run your the system in a
> sub-hurd, while watching it using ps and gdb from the working hurd. Since
> the sub-hurd is never going to make it all the way up, you don't even
> really need to make a separate filesystem for it; you can just boot the
> sub-hurd read-only on your main root filesystem if you like.
>
> The way to boot the sub-hurd is with `boot'. I would suggest something
> like this: boot -d -I -Tdevice /boot/servers.boot hd0s6
>
> The -d says to pause before the start-up of each server and wait for you to
> hit return, which gives you time to go attach gdb to the task before it
> starts running. The -I says to leave the terminal signals normal, so
> hitting C-z will suspend boot rather than sending a C-z to the virtual
> console device of the sub-hurd. (Note that suspending boot does not
> suspend the sub-hurd, just boot itself; boot acts as the server for device
> access from the sub-hurd, so the sub-hurd's attempts to write to its
> console or open devices block while boot is suspended.)
>
> When you do `ps -A' on the main hurd, the sub-hurd tasks will appear as
> unknown processes. You can figure out which is which just by looking at
> the order of unknown processes that appear with higher PIDs than the boot
> process. They appear in the order you see in the "bootstrap: ..."
> messages, i.e. the first unknown after boot will be ext2fs.static, the
> second exec, then init, then proc.
--
"Backwards compatibility is nice, but preserving every undocumented quirk
that nobody sane would use... Sorry, but we really need an addition to
errno.h: EBITEME. Exactly for such cases."
-- Alexander Viro
