Re: gcj 4.3.0 on mpc860 kernel 2.4.24

Ben Gardiner wrote:
> Andrew Haley wrote:
>> Yeah, but I need to know the intstruction *at the segfault*.
>>
>> i.e. after the segfault happens, that's whan you have to do the x/4i $pc,
>> not before.
>>   
> Sorry. Here's what you were looking for:
> -----------------------------------------
> (gdb) c
> Continuing.
> [New Thread 10733]
> 
> Program received signal SIGSEGV, Segmentation fault.
> java.lang.String.length()int (this=@30052ee8) at java/lang/String.java:451
> 451         return count;
> Current language:  auto; currently java
> (gdb) list
> 446        *
> 447        * @return the length of this String
> 448        */
> 449       public int length()
> 450       {
> 451         return count;
> 452       }
> 453
> 454       /**
> 455        * Returns the character located at the specified index within
> this String.
> (gdb) x/4i $pc
> 0xef69570 <java.lang.String.length()int>:       lwz     r3,12(r3)
> 0xef69574 <java.lang.String.length()int+4>:     blr
> 0xef69578 <java.lang.String.codePointAt(int)int>:       stwu    r1,-32(r1)
> 0xef6957c <java.lang.String.codePointAt(int)int+4>:     mflr    r0
> (gdb) p $r3
> $1 = 805646056
> -----------------------------------------
> 
>>> So the problem isn't exclusively limited to the compare_and_swap. I'm
>>> thinking now that there must be something else wrong with this
>>> toolchain. I'm sorry I bugged you on the java list. I think this is
>>> probably better suited to the ppc embedded  or cross gcc lists, of
>>> course I'll need to reproduce the problem (whatever it is) in a non-java
>>> program. :)
>>>     
>>
>> Perhaps.  At this point, I suspect the grabage collector.
> Do you still suspect the garbage collector ?

I'm not sure.  That pointer looks like it might be text data.  I think there's
something not quite right about the way structures are laid out in memory.

Andrew.