Interpreter/libffi ARM Porting

Wed Jun 16 22:14:00 GMT 2004

Hello Andrew,
Thank you very much for your detailed reply. I am afraid, however, that
we still need some more help. I hope that you'll bear with us because
we're on the brink of having a fully operational GCJ interpreter for
arm-elf-linux and arm-wince-pe. We will of course be sharing these long
overdue results with the GCC community.
Attached is my current sysv.S. It is compiling and it's working to the
point where ffitest passes and the gcj interpreter runs except for
exception handling. My test case (run on arm-elf-linux-gij) looks like
this:
class ExceptionTest {
 public static void main(String[] args) {
 System.out.println("Exception test started");
 try {
 throw new Exception("oops");
 } catch (Exception e) {
 System.out.println(e);
 e.printStackTrace();
 }
 }
}
gij is invoked as follows:
netwinder% setenv GC_INITIAL_HEAP_SIZE 3000000
netwinder% gij --cp /home/craigv/exception.jar ExceptionTest
Exception test started
Exception in thread "main" java.lang.NullPointerException
 at catch_segv
(/home/craigv/armlinux/crosstool-0.27/build/arm-elf-linux/gcc-3.3.2-glibc-2.3.2/gcc-3.3.2/libjava/prims.cc:158)
 at ExceptionTest.main(java.lang.String[]) (Unknown Source)
This is the same behavior I had seen before modifying sysv.S along the
lines you suggested. I instrumented interpret.cc and found that the
interpreter code is throwing my exception and it is being caught in the
catch block in _Jv_Interp::run(). After that it seems that I am getting
a SEGV. I have not implemented any "arm-signal.h", and so I am
currently using the default handler for SEGV in prims.cc
That is our situation. I wonder if you might be able to take a quick
look at our sysv.S and see what you think might be missing or wrong. 
Any other suggestions or ideas you might have would be HUGELY
appreciated.
Finally, it would be of great help if you could describe what is
supposed to happen when a checked exception is handled by the
interpreter. So far I have been able to figure out that the exception
is pushed onto the stack in the catch block and that its instructions
are supposed to be run next. I am not sure, but I think that it is at
this point that we are getting the segfault.
Thanks in advance,
craig vanderborgh
voxware incorporated
On Wed, 2004年06月16日 at 12:06, Andrew Haley wrote:
> Craig A. Vanderborgh writes:
> > 
> > What does this do? Is it related to exception handling in some way?
> Do
> > we need to have the equivalent thing in our ARM implementation?
>> It's the DWARF2 unwinder data.
> Yes.
> Yes.
>> You just need to tell the unwinder how to unwind through ffi_call_SYSV.
>> See http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf, page 62.
>> I suggest you compile a simple function with -fPIC -dA and have a look
> at
> the unwinder data. On x86, It will look like this:
>> int main (int argc, char **argv)
> {
> printf ("Hello, World!\n");
> return 0;
> }
>>> 		.file	"hello.c"
> 		.section	.rodata.str1.1,"aMS",@progbits,1
> 	.LC0:
> 		.string	"Hello, World!"
> 		.text
> 		.align 4
> 	.globl main
> 		.type	main, @function
> 	main:
> 	.LFB12:
> 		# basic block 0
> 		pushl	%ebp
> 	.LCFI0:
> 		movl	%esp, %ebp
> 	.LCFI1:
> 		pushl	%ebx
> 	.LCFI2:
> 		subl	4,ドル %esp
> 	.LCFI3:
> 		call	__i686.get_pc_thunk.bx
> 		addl	$_GLOBAL_OFFSET_TABLE_, %ebx
> 		andl	$-16, %esp
> 		subl	16,ドル %esp
> 		leal	.LC0@GOTOFF(%ebx), %eax
> 		movl	%eax, (%esp)
> 		call	puts@PLT
> 		movl	0,ドル %eax
> 		movl	-4(%ebp), %ebx
> 		leave
> 		ret
> 	.LFE12:
> 		.size	main, .-main
> 	#APP
>> Copy this part:
>> 		.section	.eh_frame,"a",@progbits
> 	.Lframe1:
> 		.long	.LECIE1-.LSCIE1	# Length of Common Information
> Entry
> 	.LSCIE1:
> 		.long	0x0	# CIE Identifier Tag
> 		.byte	0x1	# CIE Version
> 		.ascii "zR0円"	# CIE Augmentation
> 		.uleb128 0x1	# CIE Code Alignment Factor
> 		.sleb128 -4	# CIE Data Alignment Factor
> 		.byte	0x8	# CIE RA Column
> 		.uleb128 0x1	# Augmentation size
> 		.byte	0x1b	# FDE Encoding (pcrel sdata4)
> 		.byte	0xc	# DW_CFA_def_cfa
> 		.uleb128 0x4
> 		.uleb128 0x4
> 		.byte	0x88	# DW_CFA_offset, column 0x8
> 		.uleb128 0x1
> 		.align 4
> 	.LECIE1:
>> This is the part you need to tweak:
>> 	.LSFDE1:
> 		.long	.LEFDE1-.LASFDE1	# FDE Length
> 	.LASFDE1:
> 		.long	.LASFDE1-.Lframe1	# FDE CIE offset
> 		.long	.LFB12-.	# FDE initial location
> 		.long	.LFE12-.LFB12	# FDE address range
> 		.uleb128 0x0	# Augmentation size
>> Advance PC to LCFI0:
>> 		.byte	0x4	# DW_CFA_advance_loc4
> 		.long	.LCFI0-.LFB12
>> Call Frame Address is same as previous CFA, but at offset 8:
>> 		.byte	0xe	# DW_CFA_def_cfa_offset
> 		.uleb128 0x8
>> Call Frame Address is at r5 + offset 8:
>> 		.byte	0x85	# DW_CFA_offset, column 0x5
> 		.uleb128 0x2
>> Advance PC to LCFI1:
>> 		.byte	0x4	# DW_CFA_advance_loc4
> 		.long	.LCFI1-.LCFI0
>> Call Frame Address is in r5, same offset as before:
>> 		.byte	0xd	# DW_CFA_def_cfa_register
> 		.uleb128 0x5
>> Advance PC to LCFI3:
>> 		.byte	0x4	# DW_CFA_advance_loc4
> 		.long	.LCFI3-.LCFI1
>> Call Frame Address is in r3 + offset 12:
>> 		.byte	0x83	# DW_CFA_offset, column 0x3
> 		.uleb128 0x3
> 		.align 4
> 	.LEFDE1:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sysv.S
Type: text/x-asm
Size: 5257 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040616/e5240a74/attachment.bin>