Re: Proc failure with gcc-2.95.2

2000-03-12 Thread Roland McGrath
I've fixed the bug, and a Hurd all compiled with gcc-2.95.2 now runs fine. It turns out there was no particularly interesting reason gcc-2.95.2 exposed this bug, it was just the luck of the optimizer. The bug was that in the create_startup_proc case, where allocate_proc is called with MACH_PORT_N

Re: Proc failure with gcc-2.95.2

2000-03-11 Thread Thomas Bushnell, BSG
Chris Lingard <[EMAIL PROTECTED]> writes: > I thought perhaps that it was to do with aliasing, gcc 2-95 has changes in > strategy. > > Have you any suggestions as to how to diagnose the reason for this fault? My suggestion is to single step through startup from ld.so until main and see what ha

Re: Proc failure with gcc-2.95.2

2000-03-11 Thread Chris Lingard
Roland McGrath wrote: > > All the calls to mach_task_self() are mapped by the defines to simple > > variable __mach_task_self. There is no funtion call to initialise the > > variable. I have run nm though the object on both new Hurd and old Hurd, > > to show this. > > The initialization happens

Re: Proc failure with gcc-2.95.2

2000-03-10 Thread Roland McGrath
> All the calls to mach_task_self() are mapped by the defines to simple > variable __mach_task_self. There is no funtion call to initialise the > variable. I have run nm though the object on both new Hurd and old Hurd, > to show this. The initialization happens in the libc function `__mach_init

Re: Proc failure with gcc-2.95.2

2000-03-10 Thread Chris Lingard
I can tell you how to fix this bug; but the attached fragment of code is probably in the wrong place. All the calls to mach_task_self() are mapped by the defines to simple variable __mach_task_self. There is no funtion call to initialise the variable. I have run nm though the object on both ne

Re: Proc failure with gcc-2.95.2

2000-03-04 Thread Chris Lingard
> Have tried various starting points, new Hurd installed or old Hurd > installed. Have tried rebuilding gcc, nice to see make compare > work. With or without -O3, the fault remains the same > > new proc and new libports.so.0.2 fails > > Other permutations work > > Chris

Re: Proc failure with gcc-2.95.2

2000-03-02 Thread Roland McGrath
> PS > > Early results show that: > > new proc and new libports.so.0.2 fails > > Other permutations work Thanks for doing that testing. This is the result I would have predicted based on the failure modes we are seeing. I'd forgotten to mention the details of what little investigati

Re: Proc failure with gcc-2.95.2

2000-03-02 Thread Chris Lingard
PS Early results show that: new proc and new libports.so.0.2 fails Other permutations work Chris

Re: Proc failure with gcc-2.95.2

2000-03-02 Thread Chris Lingard
Chris Lingard wrote: > Have rebuilt the new Hurd with gcc-2.95.2. Removed all compiler > optimisation, it made no difference, it still fails; exactly the same fault > with proc. Will try something else tomorrow. > And tomorrow has come; and now I am totally confused. Messed up the new sour

Re: Proc failure with gcc-2.95.2

2000-03-01 Thread Chris Lingard
Have rebuilt the new Hurd with gcc-2.95.2. Removed all compiler optimisation, it made no difference, it still fails; exactly the same fault with proc. Will try something else tomorrow. Chris

Re: Proc failure with gcc-2.95.2

2000-02-29 Thread Chris Lingard
Hello I am too new to offer any suggestions as to cause of this bug. If anyone want to post a patch to either test a cure, or to output further diagnosics please post them. I have the latest source and both compilers, so a test is trivial. I can test anything on offer. Chris

Re: Proc failure with gcc-2.95.2

2000-02-29 Thread Marcus Brinkmann
On Tue, Feb 29, 2000 at 05:10:17PM -0500, Roland McGrath wrote: > That is, try all permutations of using old shared > libraries with the new proc, varying old vs new libraries one by one (I > mean the same exact hurd sources where "new" is compiled with gcc-2.95.2 > and "old" is compiled with anot

Re: Proc failure with gcc-2.95.2

2000-02-29 Thread Roland McGrath
Thanks for your efforts, Chris. I wound up just biting the bullet and building a gcc-2.95.2 cross-compiler on my Linux box and cross-compiling hurd with that myself last night. I'm now able to reproduce the problem you are seeing. I am still at a loss for exactly what is going on, but I only sp

Re: Proc failure with gcc-2.95.2

2000-02-29 Thread Roland McGrath
> I am still at a loss for exactly what is going on, but I only spent a > little while digging into it. It might be a while before I can spend a lot > of time looking into this, so if anyone else feels like some hardcore > debugging and wants to take a crack at it, please do. Anyone who looks >

Re: Proc failure with gcc-2.95.2

2000-02-29 Thread Chris Lingard
Hello Marcus, Roland pointed out what I should have done; attached is a better report (I hope). Debugging operating systems is new to me, I better read the man pages and a book. Chris root78 p3 S 0:00.07 boot -d -I -Tdevice /boot/servers.boot hd1s1 - 79 ? Sp0:00.13

Re: Proc failure with gcc-2.95.2

2000-02-28 Thread Marcus Brinkmann
Hi, On Mon, Feb 28, 2000 at 07:15:08PM +, Chris Lingard wrote: > Breakpoint 1, main (argc=134529024, argv=0x1, envp=0x11affa8) > at ../../proc/main.c:64 > 64struct argp argp = { 0, 0, 0, "Hurd process server" }; > (gdb) info threads > * 1 thread 125.1 main (argc=134529024, argv=0

Re: Proc failure with gcc-2.95.2

2000-02-28 Thread Chris Lingard
> > > > > fetch inferior registers: 1: Invalid thread > > This is never that useful a command. Do `info threads' here. > gdb does Attaching to program `/hurd/proc', pid 99 warning: Can't modify tracing state for pid 99: No signal thread fetch inferior registers: 1: Invalid thread (gdb) info

Re: Proc failure with gcc-2.95.2

2000-02-27 Thread Roland McGrath
> OK, a small step for you, but a giant leap for me. Your leaping is just fine. :-) > # 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

Re: Proc failure with gcc-2.95.2

2000-02-27 Thread Jeff Bailey
On Sun, Feb 27, 2000 at 10:02:01AM +, Chris Lingard wrote: > > Firstly, let me verify what we are dealing with. It was only hurd that you > > recompiled with the new gcc, not glibc, right? FWIW, my Hurds have been running Glibcs compiled with 2.95.2 since late November/early December. I ha

Re: Proc failure with gcc-2.95.2

2000-02-27 Thread Chris Lingard
> 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

Re: Proc failure with gcc-2.95.2

2000-02-25 Thread Roland McGrath
> I'm not so familiar with gdb aside from bt, print, break, step and cont. If you show us the backtrace, that might well be all we need to know. > Is there anyway to cause it to log the session to a file? Try `script gdb'.

Re: Proc failure with gcc-2.95.2

2000-02-25 Thread Jeff Bailey
On Fri, Feb 25, 2000 at 04:13:44PM -0500, Roland McGrath wrote: I'm not so familiar with gdb aside from bt, print, break, step and cont. Is there anyway to cause it to log the session to a file? > The most useful thing you can do is try to run your the system in a > sub-hurd, while watching it

Re: Proc failure with gcc-2.95.2

2000-02-25 Thread Roland McGrath
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