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

Re: Proc failure with gcc-2.95.2

Roland McGrath wrote:

> 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.

Sorry, first sent to Roland instead of here.

I have a similar situation here.  I down loaded the latest source yesterday,
and compiled with gcc-95.  Was worried that I had broken the Hurd here, so was

pleased to see this posting.  The only difference is that having only one
machine I native compile on the Hurd.

I want to follow your instructions for attaching gdb to proc. In /hurd I have
three versions of proc,  the very old one, new source with gcc from the Hurd
debs, and one built with gcc-95 that fails on boot.

I boot the Hurd up with either of the first two as the genuine proc.  Then I
overwrite proc with the one that does not work.  I use sceen to run the boot
to make a sub-Hurd.  In the first sceen I can step through the boot
processes,  in the second screen I can run ps -A,  in the third screen I can
attach gdb to the proc process.  I think I am doing it right.  The sub-boot
fails of course,  but gdb does not give any output as to why.  Am I missing a
gdb command?

The only output I got was when I replaced proc with a script  "gdb
proc.new".  I am sure this is the wrong thing to do, but it said:

memory_object_data_request(0x0, 0x0, 0x63000, 0x1000, 0x1) failed 268435459

I would be gratfull if you could tell me the step that I am missing, to
provide a gdb output as to why proc is failing.


Reply to: