This thread is also forwarded to the debian sparc list. The problem is that the boehm garbage collector (gc) test in the gcc-3.1 test suite fails on (Debian woody) sparc-linux. It might be binutils problem, it might be a gcc problem (it could perhaps be a glibc problem) and it coule be a gc problem. Any help is greatly appreciated.
If you're interested and could assist, please hop in at http://gcc.gnu.org/ml/gcc-bugs/2002-02/msg00194.html and more info on the gc can be found at http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html and the download is here: http://ginger.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc6.1alpha3.tar.gz Cheers, /ChJ On Wed, Feb 13, 2002 at 09:31:25AM -0800, Boehm, Hans wrote: > > From: Christian Jönsson [mailto:[EMAIL PROTECTED] > > > > On Tue, Feb 12, 2002 at 02:04:11PM -0800, Boehm, Hans wrote: > > > It's at least a little clearer what's going on here. But I > > think we're > > > still not making a lot of progress. My guess is that you > > have a severaly > > > broken gdb (or maybe a broken ptrace in the kernel). You > > really need to get > > > that fixed first. > > > > hmm, perhaps debian's gdb is broken, but that won't explain gc > > failure, right? > It doesn't. But it makes it far harder to debug. It might be good to check > whether the frame pointer is always wrong, e.g. by stopping it in a "hello > world" program, looking at some locals, and at "info registers". The frame > pointer and stack pointer should be close. If that also fails, you have a > simple test to send to the Debian developers. > > > > > The state at the initial SIGSEGV should not be interesting. > > That fault is > > > intentional, and it's just determining where statically > > allocated variables > > > are allocated. > > > > Is this the case when running the boehm-gc test in the gcc source tree > > also? (Then, IMHO, it's something wrong with the setup of that > > gctest...) > I believe so. It shouldn't be an issue, since the SIGSEGV is caught. You > won't notice it unlesss you're debugging. I suspect the problem there also > is a second SIGSEGV. > > > > > At the second fault, the %fp (frame pointer) register > > appears to contain > > > something that's nowhere near the stack pointer (%sp). > > That's wrong, since > > > it should point to the previous stack frame. This in turn > > explains why gdb > > > can't print values of local variables or parameters; it > > would normally find > > > those by starting with the frame pointer. > > > > Now, this shouldn't be a gdb failure, right? It's just a register > > dump, can't be too erroneously implemented but we never know... > It doesn't look plausible to me. It may well be a failure of the kernel > ptrace call to retrieve the correct registers from the process. > > > > > It's conceivable that the frame pointer was corrupted. But > > in this case, > > > even the first register dump (at the expected SIGSEGV) > > shows a similarly bad > > > frame pointer. I find it hard to believe that the process > > could have > > > correctly continued even this far if %fp was already > > corrupted there. > > > > Or are you really meaning that the register dump is wrong, i.e., that > > gdb somehow dumps the registers wrongly? (Can't it be something else > > yielding wrong values to gdb?) > > Gdb somehow gets the values wrong. That may be a kernel problem. Or it may > be that gdb uses the wrong method to retrieve them. (It might need to look > for the register values in the memory stack, and it might look in the wrong > place.) > > > > > For the optimized code you tried earlier, gdb was looking > > for some of the > > > values in registers, where it did find something. But I > > wouldn't trust that > > > either. Unfortunately, I think that means we have not much useful > > > information about what's really going on here. > > > > Sure, agreed. But still, it gctest fails, that can't be caused by gdb, > > right? > There is still an unexplained gctest failure. The problem is that we have > no reliable data to debug the problem. > > > > > If you can't get a working gdb, you might try inserting > > printfs of the > > > values I suggested earlier directly in the code. It looks like it's > > > crashing very early on, so you might not get that much output. > > > > I'll see what I can do. Perhaps we could get some help from other > > people having other variants of sparc-linux to test also. > > > I can't help much since I don't have access to a SPARC Linux system. I > agree that getting some input from the SPARC Debian developers would be > helpful. > > Hans > > > > > > > > > -----Original Message----- > > > > From: Christian Jönsson [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, February 12, 2002 12:38 PM > > > > To: Boehm, Hans > > > > Cc: 'Christian Jönsson' > > > > Subject: Re: boehm-gc test failure on sparc-linux > > > > > > > > > > > > On Tue, Feb 12, 2002 at 12:03:45PM -0800, Boehm, Hans wrote: > > > > > Could you please build with just -g? -g -O2 generally > > > > doesn't give you > > > > > reliable debug information. > > > > > > > > > > I would prefer if you did > > > > > > > > > > cp Makefile.direct Makefile; make test > > > > > > > > OK, but I changed this: > > > > > > > > [EMAIL PROTECTED]:~/gc6.1alpha3$ diff Makefile Makefile.direct > > > > 22c22 > > > > < CC=gcc-3.0 $(ABI_FLAG) > > > > --- > > > > > CC=cc $(ABI_FLAG) > > > > 33c33 > > > > < CFLAGS= -g -I$(srcdir)/include -DATOMIC_UNCOLLECTABLE > > > > -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT > > -DALL_INTERIOR_POINTERS > > > > --- > > > > > CFLAGS= -O -I$(srcdir)/include -DATOMIC_UNCOLLECTABLE > > > > -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT > > -DALL_INTERIOR_POINTERS > > > > [EMAIL PROTECTED]:~/gc6.1alpha3$ > > > > > > > > attached is the log output of make test and here's the gdb run: > > > > > > > > Current directory is ~/gc6.1alpha3/ > > > > GNU gdb 5.1 > > > > Copyright 2001 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 "sparc-linux"... > > > > (gdb) r > > > > Starting program: /home/chj/gc6.1alpha3/gctest > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > 0x00019af8 in GC_SysVGetDataStart (max_page_size=Cannot > > > > access memory at address 0x1000044 > > > > ) at os_dep.c:1055 > > > > (gdb) c > > > > Continuing. > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > 0x000199f4 in GC_find_limit (p=Cannot access memory at > > > > address 0x90022144 > > > > ) at os_dep.c:641 > > > > (gdb) print GC_stackbottom > > > > $1 = 0xf0000000 <Address 0xf0000000 out of bounds> > > > > (gdb) info registers > > > > g0 0x0 0 > > > > g1 0x67 103 > > > > g2 0x4e 78 > > > > g3 0x40614 263700 > > > > g4 0x0 0 > > > > g5 0x0 0 > > > > g6 0x0 0 > > > > g7 0x70 112 > > > > o0 0x37f00 229120 > > > > o1 0x405fc 263676 > > > > o2 0x0 0 > > > > o3 0x0 0 > > > > o4 0xf350c000 -212811776 > > > > o5 0xa 10 > > > > sp 0xefffe670 -268442000 > > > > o7 0x19a00 104960 > > > > l0 0x40000858 1073743960 > > > > l1 0x1000000 16777216 > > > > l2 0x10bfffe6 281018342 > > > > l3 0x1000000 16777216 > > > > l4 0x7fffffc3 2147483587 > > > > l5 0x1000000 16777216 > > > > l6 0xd007a048 -804806584 > > > > l7 0x80a22000 -2136858624 > > > > i0 0x12800008 310378504 > > > > i1 0x1000000 16777216 > > > > i2 0x11000101 285212929 > > > > i3 0x921221fc -1844305412 > > > > i4 0x901221fc -1877859844 > > > > i5 0xd0020000 -805175296 > > > > fp 0x90022100 -1878908672 > > > > i7 0xd0224000 -803061760 > > > > y 0x7000000 117440512 > > > > psr 0x40400081 1077936257 icc:-Z--, > > > > pil:0, s:1, ps:0, et:0, cwp:1 > > > > wim 0x0 0 > > > > tbr 0x0 0 > > > > pc 0x199f4 104948 > > > > npc 0x199f8 104952 > > > > fpsr 0x821 2081 rd:N, tem:0, ns:0, ver:0, > > > > ftt:0, qne:0, fcc:>, aexc:1, cexc:1 > > > > cpsr 0x0 0 > > > > (gdb) c > > > > Continuing. > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > 0x0001cd24 in GC_mark_from (mark_stack_top=Cannot access > > > > memory at address 0x913a2049 > > > > ) at mark.c:654 > > > > (gdb) print GC_stackbottom > > > > $2 = 0xf0000000 <Address 0xf0000000 out of bounds> > > > > (gdb) info registers > > > > g0 0x0 0 > > > > g1 0xefffe5e8 -268442136 > > > > g2 0x10 16 > > > > g3 0x10 16 > > > > g4 0x1c750 116560 > > > > g5 0x6c642d 7103533 > > > > g6 0x0 0 > > > > g7 0xffff0000 -65536 > > > > o0 0xeffff120 -268439264 > > > > o1 0xeffff120 -268439264 > > > > o2 0xefffef28 -268439768 > > > > o3 0x20 32 > > > > o4 0x500adfe4 1342889956 > > > > o5 0x5d78 23928 > > > > sp 0xefffe528 -268442328 > > > > o7 0x1d348 119624 > > > > l0 0x400009bc 1073744316 > > > > l1 0x1000000 16777216 > > > > l2 0x10bffd02 281017602 > > > > l3 0x1000000 16777216 > > > > l4 0xd007bf9c -804798564 > > > > l5 0x40000964 1073744228 > > > > l6 0x1000000 16777216 > > > > l7 0x10bffcfd 281017597 > > > > i0 0x1000000 16777216 > > > > i1 0xd007bfa0 -804798560 > > > > i2 0xd207bfa4 -771244124 > > > > i3 0x90220009 -1876819959 > > > > i4 0xd027bfa0 -802701408 > > > > i5 0xd007bfa0 -804798560 > > > > fp 0x913a2005 -1858461691 > > > > i7 0x932a2002 -1825955838 > > > > y 0x7000000 117440512 > > > > psr 0x40900080 1083179136 icc:N--C, > > > > pil:0, s:1, ps:0, et:0, cwp:0 > > > > wim 0x0 0 > > > > tbr 0x0 0 > > > > pc 0x1cd24 118052 > > > > npc 0x1cd28 118056 > > > > fpsr 0x821 2081 rd:N, tem:0, ns:0, ver:0, > > > > ftt:0, qne:0, fcc:>, aexc:1, cexc:1 > > > > cpsr 0x0 0 > > > > (gdb) print descr > > > > Cannot access memory at address 0x913a1f89 > > > > (gdb) print mark_stack > > > > Cannot access memory at address 0x913a204d > > > > (gdb) c > > > > Continuing. > > > > > > > > Program terminated with signal SIGSEGV, Segmentation fault. > > > > The program no longer exists. > > > > (gdb) quit > > > > > > > > Debugger finished > > > > > > > > > > > > Is this what you wanted? > > > > > > > > Anything else? > > > > > > > > /ChJ > > > > > >