Re: Proc failure with gcc-2.95.2
> 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?
Since you haven't shown me exactly what you did, I don't know for sure.
> 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
You mean you made /hurd/proc a #! shell script?
Nothing remotely like that is likely to work, sorry.
The proc server is essential in all normal program execution working right.
Furthermore, you need gdb to be running on top of your main hurd,
not be started inside the sub-hurd itself.
> 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.
It's been a good long while since I did this, so I surely forgot some of
the weird details I should have mentioned. Seeing the actual transcript of
your session always helps jog my memory on these things.
Firstly, let me verify what we are dealing with. It was only hurd that you
recompiled with the new gcc, not glibc, right?
The way the -d booting pause works is that init creates the bare task, then
says "Pausing for proc" and waits for you to hit a key. When you hit a
key, then it does file_exec to load the image into the task. So in between
is your window to attach gdb. During this time, the task is completely
empty; it has no memory and no threads yet, and so there is nothing to set
a breakpoint on. So what you must do is attach gdb, then hit return to
init so it loads the task, and only then can you use gdb to try to do
anything useful to the task. (When gdb attaches to a process, it suspends
the task, which prevents any threads from running in that task but does not
prevent task control operations. So, while gdb has the task suspended,
exec can come in and do all the operations to load memory into the task and
set up its first thread ready to run; the task will just sit ready to run
until gdb resumes it. gdb can get a little confused by the state of the
task changing while it's suspended; usually just an "info threads" after
the exec does its thing will make gdb recombobulate itself.
So now you have gdb attached to proc, and you can see its initial thread
ready to start executing the startup code. Note that this will not be
proc's entry point, but the dynamic linker's entry point. You ought to be
able to set a breakpoint at main and continue until there. Try that to see
if everything is working ok with gdb. If that works, then you should then
just be able to continue and see the crash. If not, then there is
something else funny going on that I'm not remembering right.
The issue with attaching so early to any other process (except init and
proc) is that the C library's startup resets the task exception port, to
let the process's own signal thread handle its exceptions and turn them
into signals. But proc is a special beastie and never has a signal thread,
so this should not be the problem in this case.
Reply to: