From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-17338-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4710 invoked by alias); 15 Apr 2002 21:46:09 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 4673 invoked by uid 71); 15 Apr 2002 21:46:05 -0000
Date: Mon, 15 Apr 2002 14:46:00 -0000
Message-ID: <20020415214604.4671.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Tom Tromey <tromey@redhat.com>
Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu 	res with -m64
Reply-To: Tom Tromey <tromey@redhat.com>
X-SW-Source: 2002-04/txt/msg00801.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR java/6092; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: "Boehm, Hans" <hans_boehm@hp.com>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, gcc-gnats@gcc.gnu.org
Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu 	res with -m64
Date: 15 Apr 2002 15:41:52 -0600

 Hans> That line in GC_stopped_mark calls GC_mark_some.  Thus I would
 Hans> conclude that this version of gdb is only partially functional,
 Hans> and it actually dies somewhere in GC_mark_some().
 
 I agree.
 
 Hans> A possible cause of that is confusion about where the roots are.
 Hans> If you can check GC_stackbottom, check that the collector and
 Hans> libgcj configuration agree on threads, get GC_dump() output, and
 Hans> check the root locations against the nm output that might
 Hans> identify something.  Otherwise we need better debug information.
 
 In order to reduce the number of variables a bit, I tried gctest.  I
 got the same problem.  Here's some info.
 
 (gdb) call GC_dump()
 ***Static roots:
 From 0x100106000 to 0x10012d8b8 
 Total size: 161976
 
 ***Heap sections:
 Total heap size: 131072
 Section 0 from 0x100178000 to 0x100198000 0/16 blacklisted
 
 ***Free blocks:
 Free list 16 (Total size 131072):
 	0x100178000 size 131072 not black listed
 Total of 131072 bytes on free list
 
 ***Blocks in use:
 (kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, #_marks_set)
 
 blocks = 0, bytes = 0
 
 
 
 (gdb) p GC_stackbottom
 $3 = 0xffffffff80000000 <Address 0xffffffff80000000 out of bounds>
 
 I dug through the source a bit.  I think this machine doesn't define
 USERLIMIT (a simple test program fails), so we must be using HEURISTIC2.
 
 
 When using nm what am I looking for?  I looked at one global,
 GC_gc_no.  Its address falls into the range that GC_dump prints for
 the static roots.  Should I do this comparison for all the globals?
 
 Tom