Re: [patch] Fix oddity in personality routine

Jack Howarth wrote:
> On Wed, Dec 02, 2009 at 09:34:33AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Tue, Dec 01, 2009 at 05:24:29PM +0000, Andrew Haley wrote:
>>>> Jack Howarth wrote:
>>>>> On Tue, Dec 01, 2009 at 09:29:36AM +0000, Andrew Haley wrote:
>>>>>> Jack Howarth wrote:
>>>>>>
>>>>>>> (gdb) 
>>>>>>> 54	  (*real_main) (args);
>>>>>>> (gdb) 
>>>>>>>
>>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>>>> 51	RowSetEvent.java: No such file or directory.
>>>>>>> 	in RowSetEvent.java
>>>>>>> (gdb) 
>>>>>>>
>>>>>>> A backtrace only shows...
>>>>>>>
>>>>>>> (gdb) bt
>>>>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>>>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>>>>>
>>>>>>> Let me know if you have any suggestions for debugging this further.
>>>>>> Disassemble the first 10 or so instructions at the instruction where the
>>>>>> EXC_BAD_ACCESS occurs.  I think this is a libffi bug.
>>>>>>
>>>>>> Andrew.
>>>>> Andrew,
>>>>>    So just to clarify, for the instance of...
>>>>>
>>>>> -------------------
>>>>>
>>>>> (gdb) 
>>>>> 0x00000001004168df in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=9) at Modifier.java:258
>>>>> 258	    return (mod & PUBLIC) != 0;
>>>>> (gdb) 
>>>>> gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
>>>>> 46	    msg =  "`main' must be public";
>>>>> (gdb) 
>>>>> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
>>>>> (gdb) 
>>>>> 54	  (*real_main) (args);
>>>>> (gdb) 
>>>>>
>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
>>>>> 0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>> 51	RowSetEvent.java: No such file or directory.
>>>>> 	in RowSetEvent.java
>>>>> (gdb) 
>>>>>
>>>>> A backtrace only shows...
>>>>>
>>>>> (gdb) bt
>>>>> #0  0x0000000103f05db0 in ?? () at RowSetEvent.java:51
>>>>> #1  0x00000001000485be in gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
>>>>> Previous frame inner to this frame (gdb could not unwind past this frame)
>>>>>
>>>>> -----------------
>>>>>
>>>>> I want to disassemble from 0x00000001000485be, right?
>>>> 0x0000000103f05db0, where the fault happens.  I think it's a libffi stub,
>>>> and I think its page permissions are not correctly set.
>>>>
>>>> But let's see.
>>>>
>>>> What I would do is, at
>>>>
>>>>> 54	  (*real_main) (args);
>>>> disassemble the call instruction, it's probably  call ($rax)  or somesuch.
>>>> look in $rax with
>>>>
>>>> p $rax
>>>>
>>>> and disassemble from the address that's in there.
>>>>
>>>> Andrew.
>>> Andrew,
>>>    I can't disassemble 0x0000000103f05db0...
>>>
>>> (gdb) disassemble 0x0000000103f05db0
>>> No function contains specified address.
>> x/10i 0x0000000103f05db0
>>
>> Andrew.
> 
> Andrew,
>    Okay, I see...
> 
> gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
> ...
> gdb) break ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> Breakpoint 1 at 0x20c49ba4b0a5ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
> (gdb) r testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
> Starting program: /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1 testme.java -fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccQOWl1c.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//cc4p4DHj.jar
> warning: posix_spawn failed, trying execvp, error: 86
> Reading symbols for shared libraries +++++.. done
> Breakpoint 1 at 0x1000485ab: file ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc, line 46.
> 
> Breakpoint 1, gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:46
> 46	    msg =  "`main' must be public";
> (gdb) s
> Current language:  auto; currently c++
> 45	  else if (! ::java::lang::reflect::Modifier::isPublic(meth->accflags))
> (gdb) s
> 54	  (*real_main) (args);
> (gdb) x/10i 0x0000000103f05db0
> 0x103f05db0:	mov    $0x1009814e8,%r11
> 0x103f05dba:	mov    $0x103f05db0,%r10
> 0x103f05dc4:	clc    
> 0x103f05dc5:	rex.WB jmpq   *%r11
> 0x103f05dc8:	add    %bl,-0x10(%rsi)
> 0x103f05dcb:	add    (%rcx),%eax
> 0x103f05dcd:	add    %al,(%rax)
> 0x103f05dcf:	add    %ah,%al
> 0x103f05dd1:	(bad)  
> 0x103f05dd2:	cwtl   
> (gdb) bt
> #0  gnu::java::lang::MainThread::call_main (this=0x104875dc0) at ../../../gcc-4.5-20091128/libjava/gnu/java/lang/natMainThread.cc:54
> #1  0x0000000104875dc0 in ?? () at ClassHelper.java:106
> #2  0x0000000104875f00 in ?? () at ClassHelper.java:106
> #3  0x000000010493e980 in ?? () at ClassHelper.java:106
> #4  0x00000001000b1b74 in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x104875dc0) at MainThread.java:106
> Previous frame inner to this frame (gdb could not unwind past this frame)
> (gdb) p $rax
> $1 = 1
> 
> (gdb) s
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0000000103f05db0
> 0x0000000103f05db0 in ?? () at ClassHelper.java:106
> 106	ClassHelper.java: No such file or directory.
> 	in ClassHelper.java
> 
> What do you make of the bad assembly at 0x103f05dd1?

There is no bad assembly: there's a jump at 0x103f05dc5.

I know what's going on.

The OS forbids execution of memory in the heap.  But, there is an extra
flag, -Wl,-allow_stack_execute, that allows this permission.  This is
a misnamed flag, since we never execute code on the stack.  I think it's
really controlling heap execution, not stack execution.

We need to pass this flag everywhere, whenever a program is compiled by
gcj.

Andrew.