Re: Proc failure with gcc-2.95.2
> Firstly, let me verify what we are dealing with. It was only hurd that you
> recompiled with the new gcc, not glibc, right?
Yes, just compiling the Hurd. The source that I have been using is fairly old; so
last Friday I had the chance to download a completely fresh version. Have the
standard gcc 2.91.66-1.2; plus a native built gcc 2.95.2 in /usr/local/bin.
> 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.
>
> --
OK, a small step for you, but a giant leap for me. I boot the Hurd using a
working proc, then overwrite proc with the gcc-95 version. I use the screen
program and here are the results:
Screen 1)
boot -d -I -Tdevice /boot/servers.boot hd1s1
Pausing. . .
/hurd/ext2fs.static --bootflags=-df --host-priv-port=114 --device-master-port=119
--exec-server-task=123 -Tdevice hd1s1
/lib/ld.so.1 /hurd/exec
ext2fs: hd1s1: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEASE fsck
ext2fs: hd1s1: warning: MOUNTED READ-ONLY; MUST USE `fsysopts --writable'
Hurd server bootstrap: ext2fs.static[hd1s1]
pausing for exec
exec
pausing for /hurd/init...
initPausing for /hurd/proc
### This is
where I attach gdb
### Then I
return here and press return
procPausing for /hurd/auth
### It
freezes here until gdb has finished
auth/hurd/init: Crashing system; proc server died during bootstrap
init: Would reboot Mach with flags 0
/hurd/auth: cannot contact init for bootstrap: (ipc/mig) server died
Script done on Sun Feb 27 09:31:34 2000
Screen 2)
root 91 p3 0 S 0:00.05 boot -d -I -Tdevice /boot/servers.boot hd1s1
- 92 ? 0 Sp 0:00.10 ?
- 93 ? 0 Sp 0:00.01 ?
- 94 ? 0 Sp 0:00.02 ?
- 95 ? 0 p 0:00.00 ?
root 96 p5 0 S 0:00.04 ps -A
# gdb /hurd/proc 95
GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-gnu0.2"...
/home/cal/95: No such file or directory.
Attaching to program `/hurd/proc', pid 95
warning: Can't modify tracing state for pid 95: No signal thread
fetch inferior registers: 1: Invalid thread
###
After return from screen 1
(gdb) list
57 main (int argc, char **argv, char **envp)
58 {
59 mach_port_t boot;
60 error_t err;
61 mach_port_t pset, psetcntl;
62 void *genport;
63 process_t startup_port;
64 struct argp argp = { 0, 0, 0, "Hurd process server" };
65
66 argp_parse (&argp, argc, argv, 0, 0, 0);
(gdb) b 57
Breakpoint 1 at 0x804c000: file ../../proc/main.c, line 57.
(gdb) cont
Continuing.
warning: Can't wait for pid 95: No child processes
Breakpoint 1, main (argc=134529024, argv=0x1, envp=0x11affa8)
at ../../proc/main.c:64
64 struct argp argp = { 0, 0, 0, "Hurd process server" };
(gdb) cont
Continuing.
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x11738f8 in ?? () from /lib/libmachuser.so.1
(gdb) cont
Continuing.
fetch inferior registers: 1: Invalid thread
fetch inferior registers: 1: Invalid thread
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program `/hurd/proc' pid 95
# exit
exit
Script done on Sun Feb 27 09:31:27 2000
Hope this helps. Any further advice and requests for more information welcome
Chris
> To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: