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.
Chris
Reply to: