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
