[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: remote debugging stubs (neighbourhurds)

From: Marco Gerards
Subject: Re: remote debugging stubs (neighbourhurds)
Date: 08 Sep 2003 23:10:35 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greg Buchholz <> writes:

> On Mon, 8 Sep 2003, Marcus Brinkmann wrote:
> > The way you'd normally do that is using the "boot" command and booting a
> > second Hurd system in parallel to the first one.  Then you can attach gdb to
> > the processes inside the second Hurd.
>       I tried the "boot" command, but my setup didn't fail in the same
> way that an actual boot does.  But the more I think about it, maybe
> "boot" doesn't work in the way that I initially thought.  Here's what I
> tried...
> #boot -D/cdrom servers.boot /dev/hd2

That's seems correct to me.  Using "-d" to pause seems a good idea
here.  (That's what I meant with the pause to attach).
> ...which resulted in a couple/three of lines of output...
> /hurd/iso9660fs.statis --multi-boot-command yada,yada,yada
> /hurd/ /hurd/exec
> bye

This is weird. Is /hurd/exec on the fs. Is there a /server/* ?  Attach
gdb to the fs. to see what it its loading.

> ...which is not the output I get when I just boot the CD.  But now I'm
> thinking that maybe the subHurd doesn't have a console to display on, so
> any messages end up in the equivalent of /dev/null.  Is that correct?
> What should a person expect to see when booting a subHurd?  I read the
> following article about subhurds...

No, it will end up on your console.  Your current (virtual)
console will be used as console.

> ...Is there any other documentation about neighbourhurds available?

Read the Hurd reference guide (info hurd).

>       I'll try the "boot" command again, but this time I'll actually try
> to attach gdb.

Ah :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]