java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu res with -m64

[Tom Tromey]

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