Re: remote debugging stubs (neighbourhurds)

[Marco Gerards]

Greg Buchholz <sleepingsquirrel@sleepingsquirrel.org> 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/ld.so.1 /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.

> http://www.gnu.org/software/hurd/howto/subhurd.html
> 
> ...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 :)

Thanks,
Marco