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
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
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
> 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
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
> 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
> 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
PS
Early results show that:
new proc and new libports.so.0.2 fails
Other permutations work
Chris
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
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
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
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
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
> 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
>
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
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
>
> >
> > 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
> 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
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
> 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
> 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'.
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
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
23 matches
Mail list logo