[PATCH/RFA] libjava: SH support

[PATCH/RFA] libjava: SH support

[kaz Kojima]

Hi,

This patch for mailine adds preliminary SH support for libjava.
Bootstrapped and regtested on sh4-unknown-linux-gnu.

BTW, I've got
                === libjava Summary ===

# of expected passes            2440
# of unexpected failures        75
# of expected failures          14
# of untested testcases         191

with make check. Are 75 failures too many?

	kaz
--
2002-07-24  Kaz Kojima  <kkojima@gcc.gnu.org>

	* configure.host: Add SH support.
        * sysdep/sh/locks.h: New file.

diff -urN ORIG/gcc/libjava/configure.host LOCAL/gcc/libjava/configure.host
--- ORIG/gcc/libjava/configure.host     Mon Jul 22 08:11:37 2002
+++ LOCAL/gcc/libjava/configure.host    Mon Jul 22 08:42:14 2002
@@ -125,6 +125,12 @@
 	enable_getenv_properties_default=no
 	enable_main_args_default=no
 	;;
+  sh-* | sh[34]*-*)
+	sysdeps_dir=sh
+	libgcj_flags="${libgcj_flags} -mieee"
+	libgcj_interpreter=yes
+	enable_hash_synchronization_default=yes
+	;;
 esac
 
 # This case statement supports generic port properties and may refine
diff -urN ORIG/gcc/libjava/sysdep/sh/locks.h LOCAL/gcc/libjava/sysdep/sh/locks.h
--- ORIG/gcc/libjava/sysdep/sh/locks.h	Thu Jan  1 09:00:00 1970
+++ LOCAL/gcc/libjava/sysdep/sh/locks.h	Sun Jul 21 17:45:26 2002
@@ -0,0 +1,72 @@
+// locks.h - Thread synchronization primitives. SuperH implementation.
+
+/* Copyright (C) 2002  Free Software Foundation
+
+   This file is part of libgcj.
+
+This software is copyrighted work licensed under the terms of the
+Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
+details.  */
+
+#ifndef __SYSDEP_LOCKS_H__
+#define __SYSDEP_LOCKS_H__
+
+typedef size_t obj_addr_t;	/* Integer type big enough for object	*/
+				/* address.				*/
+
+static unsigned char __cas_lock = 0;
+
+inline static void
+__cas_start_atomic (void)
+{
+  unsigned int val;
+
+  do
+    __asm__ __volatile__ ("tas.b @%1; movt %0"
+			  : "=r" (val)
+			  : "r" (&__cas_lock)
+			  : "memory");
+  while (val == 0);
+}
+
+inline static void
+__cas_end_atomic (void)
+{
+  __asm__ __volatile__ (" " : : : "memory");
+  __cas_lock = 0;
+}
+
+inline static bool
+compare_and_swap (volatile obj_addr_t *addr, obj_addr_t old,
+		  obj_addr_t new_val)
+{
+  bool ret;
+
+  __cas_start_atomic ();
+  if (*addr != old)
+    ret = false;
+  else
+    {
+      *addr = new_val;
+      ret = true;
+    }
+  __cas_end_atomic ();
+
+  return ret;
+}
+
+inline static void
+release_set (volatile obj_addr_t *addr, obj_addr_t new_val)
+{
+  __asm__ __volatile__ (" " : : : "memory");
+  *(addr) = new_val;
+}
+
+inline static bool
+compare_and_swap_release (volatile obj_addr_t *addr, obj_addr_t old,
+			  obj_addr_t new_val)
+{
+  return compare_and_swap (addr, old, new_val);
+}
+
+#endif /* ! __SYSDEP_LOCKS_H__ */

Re: [PATCH/RFA] libjava: SH support

[Jeff Sturm]

On Wed, 24 Jul 2002, kaz Kojima wrote:
>                 === libjava Summary ===
>
> # of expected passes            2440
> # of unexpected failures        75
> # of expected failures          14
> # of untested testcases         191

Does this port have a working MD_FALLBACK_FRAME_STATE_FOR?  This is
necessary to unwind through signal handler frames.  Without it you can set
CHECKREFSPEC, EXCEPTIONSPEC as is done for e.g. xscale*-elf:

    CHECKREFSPEC=-fcheck-references
    EXCEPTIONSPEC=

Jeff

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Jeff Sturm <jsturm@one-point.com> writes:
> On Wed, 24 Jul 2002, kaz Kojima wrote:
>>                 === libjava Summary ===
>>
>> # of expected passes            2440
>> # of unexpected failures        75
>> # of expected failures          14
>> # of untested testcases         191
> 
> Does this port have a working MD_FALLBACK_FRAME_STATE_FOR?  This is
> necessary to unwind through signal handler frames.  Without it you can set
> CHECKREFSPEC, EXCEPTIONSPEC as is done for e.g. xscale*-elf:
> 
>     CHECKREFSPEC=-fcheck-references
>     EXCEPTIONSPEC=

SH port doesn't implement the dwarf-2 exception handler and doesn't
have a working MD_FALLBACK_FRAME_STATE_FOR yet. I'll add these 2
lines and build libgcj again.

Thanks,
	kaz

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:
> Jeff Sturm <jsturm@one-point.com> writes:
>> On Wed, 24 Jul 2002, kaz Kojima wrote:
>>>                 === libjava Summary ===
>>>
>>> # of expected passes            2440
>>> # of unexpected failures        75
>>> # of expected failures          14
>>> # of untested testcases         191
>> 
>> Does this port have a working MD_FALLBACK_FRAME_STATE_FOR?  This is
>> necessary to unwind through signal handler frames.  Without it you can set
>> CHECKREFSPEC, EXCEPTIONSPEC as is done for e.g. xscale*-elf:
>> 
>>     CHECKREFSPEC=-fcheck-references
>>     EXCEPTIONSPEC=
>
> SH port doesn't implement the dwarf-2 exception handler and doesn't
> have a working MD_FALLBACK_FRAME_STATE_FOR yet. I'll add these 2
> lines and build libgcj again.

Done. Now, 75 unexpected failures reduces to 65. Thanks Jeff.
Here is a revised patch.

Thanks,
	kaz
--
2002-07-25  Kaz Kojima  <kkojima@gcc.gnu.org>

	* configure.host: Add SH support.
        * sysdep/sh/locks.h: New file.

diff -urN ORIG/gcc/libjava/configure.host LOCAL/gcc/libjava/configure.host
--- ORIG/gcc/libjava/configure.host	Mon Jul 22 08:11:37 2002
+++ LOCAL/gcc/libjava/configure.host	Wed Jul 24 12:17:59 2002
@@ -125,6 +125,14 @@
 	enable_getenv_properties_default=no
 	enable_main_args_default=no
 	;;
+  sh-* | sh[34]*-*)
+	sysdeps_dir=sh
+	libgcj_flags="${libgcj_flags} -mieee"
+	libgcj_interpreter=yes
+	CHECKREFSPEC=-fcheck-references
+	EXCEPTIONSPEC=
+	enable_hash_synchronization_default=yes
+	;;
 esac
 
 # This case statement supports generic port properties and may refine
diff -urN ORIG/gcc/libjava/sysdep/sh/locks.h LOCAL/gcc/libjava/sysdep/sh/locks.h
--- ORIG/gcc/libjava/sysdep/sh/locks.h	Thu Jan  1 09:00:00 1970
+++ LOCAL/gcc/libjava/sysdep/sh/locks.h	Sun Jul 21 17:45:26 2002
@@ -0,0 +1,72 @@
+// locks.h - Thread synchronization primitives. SuperH implementation.
+
+/* Copyright (C) 2002  Free Software Foundation
+
+   This file is part of libgcj.
+
+This software is copyrighted work licensed under the terms of the
+Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
+details.  */
+
+#ifndef __SYSDEP_LOCKS_H__
+#define __SYSDEP_LOCKS_H__
+
+typedef size_t obj_addr_t;	/* Integer type big enough for object	*/
+				/* address.				*/
+
+static unsigned char __cas_lock = 0;
+
+inline static void
+__cas_start_atomic (void)
+{
+  unsigned int val;
+
+  do
+    __asm__ __volatile__ ("tas.b @%1; movt %0"
+			  : "=r" (val)
+			  : "r" (&__cas_lock)
+			  : "memory");
+  while (val == 0);
+}
+
+inline static void
+__cas_end_atomic (void)
+{
+  __asm__ __volatile__ (" " : : : "memory");
+  __cas_lock = 0;
+}
+
+inline static bool
+compare_and_swap (volatile obj_addr_t *addr, obj_addr_t old,
+		  obj_addr_t new_val)
+{
+  bool ret;
+
+  __cas_start_atomic ();
+  if (*addr != old)
+    ret = false;
+  else
+    {
+      *addr = new_val;
+      ret = true;
+    }
+  __cas_end_atomic ();
+
+  return ret;
+}
+
+inline static void
+release_set (volatile obj_addr_t *addr, obj_addr_t new_val)
+{
+  __asm__ __volatile__ (" " : : : "memory");
+  *(addr) = new_val;
+}
+
+inline static bool
+compare_and_swap_release (volatile obj_addr_t *addr, obj_addr_t old,
+			  obj_addr_t new_val)
+{
+  return compare_and_swap (addr, old, new_val);
+}
+
+#endif /* ! __SYSDEP_LOCKS_H__ */

Re: [PATCH/RFA] libjava: SH support

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz> Done. Now, 75 unexpected failures reduces to 65. Thanks Jeff.
kaz> Here is a revised patch.

I don't think it needs to delay this patch, but could you post a list
of the failing tests?  Sometimes we can tell something useful just
based on that.

kaz> 2002-07-25  Kaz Kojima  <kkojima@gcc.gnu.org>
kaz> 	* configure.host: Add SH support.
kaz>         * sysdep/sh/locks.h: New file.

The configure.host part looks fine to me.
Someone else will have to say whether the SH assembly code is ok.
(Maybe that person is you, I don't know.)

Could you write a news entry for java/index.html explaining that this
port has been done?

Tom

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> I don't think it needs to delay this patch, but could you post a list
> of the failing tests?  Sometimes we can tell something useful just
> based on that.

OK. Here is a list of the unexpected failures:

FAIL: PR1343 compilation from bytecode
FAIL: PR1343 -O compilation from bytecode
Exception in thread "main" FAIL: calls run
Exception in thread "main" FAIL: cxxtest run
Exception in thread "main" FAIL: field run
Exception in thread "main" FAIL: final_method run
Exception in thread "main" FAIL: findclass run
Exception in thread "main" FAIL: invoke run
Exception in thread "main" FAIL: martin run
Exception in thread "main" FAIL: noclass run
Exception in thread "main" FAIL: overload run
Exception in thread "main" FAIL: register run
Exception in thread "main" FAIL: simple_int run
Exception in thread "main" FAIL: throwit run
Exception in thread "main" FAIL: virtual run
FAIL: ArrayStore execution - gij test
FAIL: ArrayStore execution - gij test
FAIL: ArrayStore2 execution - gij test
FAIL: ArrayStore2 execution - gij test
FAIL: Array_3 execution - gij test
FAIL: Array_3 compilation from bytecode
FAIL: Array_3 execution - gij test
FAIL: Array_3 -O compilation from bytecode
FAIL: Divide_1 execution - gij test
FAIL: Divide_1 execution - gij test
FAIL: Final output - gij test
FAIL: Final output - gij test
FAIL: G19990302_02 execution - gij test
FAIL: G19990302_02 execution - gij test
FAIL: G19990303_01 execution - gij test
FAIL: G19990303_01 execution - gij test
FAIL: G19990303_02 execution - gij test
FAIL: G19990303_02 execution - gij test
FAIL: G19990304_01 execution - gij test
FAIL: G19990304_01 execution - gij test
FAIL: InterfaceDispatch execution - gij test
FAIL: InterfaceDispatch execution - gij test
FAIL: Invoke_1 output - gij test
FAIL: Invoke_1 output - gij test
FAIL: PR141 output - gij test
FAIL: PR141 output - gij test
FAIL: PR218 execution - gij test
FAIL: PR218 execution - gij test
FAIL: StringBuffer_1 execution - gij test
FAIL: StringBuffer_1 execution - gij test
FAIL: TLtest compilation from bytecode
FAIL: TLtest -O compilation from bytecode
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 execution - bytecode->native test
FAIL: Throw_2 -O execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 -O execution - bytecode->native test
FAIL: inner4 output - gij test
FAIL: inner4 output - gij test
FAIL: instinit2 execution - gij test
FAIL: instinit2 execution - gij test
FAIL: invokethrow execution - gij test
FAIL: invokethrow execution - gij test
FAIL: negzero output - gij test
FAIL: negzero output - gij test
FAIL: pr184 execution - gij test
FAIL: pr184 execution - gij test
FAIL: pr83 execution - gij test
FAIL: pr83 execution - gij test

13 jni tests seems to fail with a non-java issue. I'll look them
and gij errors more closely. 

>> 2002-07-25  Kaz Kojima  <kkojima@gcc.gnu.org>
>> 	* configure.host: Add SH support.
>>         * sysdep/sh/locks.h: New file.
> 
> The configure.host part looks fine to me.
> Someone else will have to say whether the SH assembly code is ok.
> (Maybe that person is you, I don't know.)

This assembly code is a copy&paste form GNU libc. Anyway, I'd
like to wait the approval by SH experts.
 
> Could you write a news entry for java/index.html explaining that this
> port has been done?

Is this ok?

Index: index.html
===================================================================
RCS file: /cvsroot/gcc/wwwdocs/htdocs/java/index.html,v
retrieving revision 1.109
diff -u -r1.109 index.html
--- index.html	22 Jul 2002 03:59:02 -0000	1.109
+++ index.html	25 Jul 2002 10:07:25 -0000
@@ -74,6 +74,13 @@
 <!-- News entries start here -->
 
 <tr><td valign="top">
+<b>July 25, 2002</b>
+</td><td>
+Kaz Kojima has implemented the necessary support in FFI and libjava
+to get libgcj running on SH-3/4.
+</td></tr>
+
+<tr><td valign="top">
 <b>July 19, 2002</b>
 </td><td>
 Bo Thorsen, SuSE Labs, has implemented the necessary support in FFI,

Thanks a lot,
	kaz

Re: [PATCH/RFA] libjava: SH support

[Jeff Sturm]

On Thu, 25 Jul 2002, kaz Kojima wrote:
> OK. Here is a list of the unexpected failures:
...
> FAIL: ArrayStore execution - gij test
> FAIL: ArrayStore execution - gij test
> FAIL: ArrayStore2 execution - gij test
> FAIL: ArrayStore2 execution - gij test

Each of these failed in the interpreter, and involve exception handling.

Perhaps all you are missing is DWARF-2 unwind info for the assembly
routines in libffi.

Jeff

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Jeff Sturm <jsturm@one-point.com> wrote:
> On Thu, 25 Jul 2002, kaz Kojima wrote:
>> OK. Here is a list of the unexpected failures:
>...
>> FAIL: ArrayStore execution - gij test
>> FAIL: ArrayStore execution - gij test
>> FAIL: ArrayStore2 execution - gij test
>> FAIL: ArrayStore2 execution - gij test
>
> Each of these failed in the interpreter, and involve exception handling.
> 
> Perhaps all you are missing is DWARF-2 unwind info for the assembly
> routines in libffi.

Is DWARF-2 unwind info required even when sjlj exceptions are used?

	kaz

Re: [PATCH/RFA] libjava: SH support

[Andrew Haley]

kaz Kojima writes:
 > Jeff Sturm <jsturm@one-point.com> wrote:
 > > On Thu, 25 Jul 2002, kaz Kojima wrote:
 > >> OK. Here is a list of the unexpected failures:
 > >...
 > >> FAIL: ArrayStore execution - gij test
 > >> FAIL: ArrayStore execution - gij test
 > >> FAIL: ArrayStore2 execution - gij test
 > >> FAIL: ArrayStore2 execution - gij test
 > >
 > > Each of these failed in the interpreter, and involve exception handling.
 > > 
 > > Perhaps all you are missing is DWARF-2 unwind info for the assembly
 > > routines in libffi.
 > 
 > Is DWARF-2 unwind info required even when sjlj exceptions are used?

It shouldn't be.  It looks like C++ can't catch exceptions thrown from
Java.

Was the whole toolchain configured using sjlj exceptions?

Andrew.

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Andrew Haley <aph@cambridge.redhat.com> writes:
> kaz Kojima writes:
>...
>> Is DWARF-2 unwind info required even when sjlj exceptions are used?
> 
> It shouldn't be.  It looks like C++ can't catch exceptions thrown from
> Java.
> 
> Was the whole toolchain configured using sjlj exceptions?

Yep, though I'd like to check it again. Anyway, it's a great hint
for me. Thanks a lot Andrew and Jeff.

	kaz

Re: [PATCH/RFA] libjava: SH support

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz> 13 jni tests seems to fail with a non-java issue.

Yesterday I checked in a fix that might help the JNI failures.
It did for me.

kaz> Is this ok?

kaz>  <tr><td valign="top">
kaz> +<b>July 25, 2002</b>
kaz> +</td><td>
kaz> +Kaz Kojima has implemented the necessary support in FFI and libjava
kaz> +to get libgcj running on SH-3/4.
kaz> +</td></tr>

Looks great, thanks.  Please check it in.

Tom

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> kaz> 13 jni tests seems to fail with a non-java issue.
> 
> Yesterday I checked in a fix that might help the JNI failures.
> It did for me.

I'll try it. Thanks!
In my case, all jni tests failed like as:

  java.lang.UnsatisfiedLinkError: calls: file not found

and I suspect that there is something wrong with dynamic loading
in my platform.

> kaz> Is this ok?
> 
> kaz>  <tr><td valign="top">
> kaz> +<b>July 25, 2002</b>
> kaz> +</td><td>
> kaz> +Kaz Kojima has implemented the necessary support in FFI and libjava
> kaz> +to get libgcj running on SH-3/4.
> kaz> +</td></tr>
> 
> Looks great, thanks.  Please check it in.

I've checked it in.

Thanks,
	kaz

Re: [PATCH/RFA] libjava: SH support

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz>   java.lang.UnsatisfiedLinkError: calls: file not found
kaz> and I suspect that there is something wrong with dynamic loading
kaz> in my platform.

There was a bug in Runtime that might have caused just this.

Tom

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> kaz>   java.lang.UnsatisfiedLinkError: calls: file not found
> kaz> and I suspect that there is something wrong with dynamic loading
> kaz> in my platform.
> 
> There was a bug in Runtime that might have caused just this.

After updating libjava, all jni tests are passed. Thanks!

	kaz

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:
>> Was the whole toolchain configured using sjlj exceptions?
> 
> Yep, though I'd like to check it again. Anyway, it's a great hint
> for me. Thanks a lot Andrew and Jeff.

I've found a cause of many gij failures on SH port.
Interpreter takes JVM stack and local variables as variable
sized arrays:

void
_Jv_InterpMethod::run (void *retp, ffi_raw *args)
{
  using namespace java::lang::reflect;

  _Jv_word stack[max_stack];
  _Jv_word *sp = stack;

  _Jv_word locals[max_locals];
  ...

and the compiler generates the code which _Unwind_SjLj_Register
is called _before_ allocating machine stack for these arrays.
So the stack pointer is set to the higher address than these
arrays when the exception threw, and the contents of these arrays
are clobbered. I don't know how to fix it.

As a test, if these arrays are allocated by GC_malloc_atomic,
then the remained failures are

FAIL: PR1343 compilation from bytecode
FAIL: PR1343 -O compilation from bytecode
FAIL: zeroexp compilation from source
FAIL: zeroexp byte compilation
FAIL: zeroexp -O compilation from source
FAIL: zeroexp byte compilation
FAIL: Array_3 execution - gij test
FAIL: Array_3 compilation from bytecode
FAIL: Array_3 execution - gij test
FAIL: Array_3 -O compilation from bytecode
FAIL: PR141 output - gij test
FAIL: PR141 output - gij test
FAIL: PR218 execution - gij test
FAIL: PR218 execution - gij test
FAIL: TLtest compilation from bytecode
FAIL: TLtest -O compilation from bytecode
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 execution - bytecode->native test
FAIL: Throw_2 -O execution - source compiled test
FAIL: Throw_2 execution - gij test
FAIL: Throw_2 -O execution - bytecode->native test
FAIL: inner4 output - gij test
FAIL: inner4 output - gij test
FAIL: negzero output - gij test
FAIL: negzero output - gij test

Regards,
	kaz

Re: [PATCH/RFA] libjava: SH support

[Alexandre Oliva]

On Jul 26, 2002, kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:

> kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:
>>> Was the whole toolchain configured using sjlj exceptions?
>> 
>> Yep, though I'd like to check it again. Anyway, it's a great hint
>> for me. Thanks a lot Andrew and Jeff.

> I've found a cause of many gij failures on SH port.
> Interpreter takes JVM stack and local variables as variable
> sized arrays:

Do you have a testcase that easily exposes the problem (even if one
has to inspect the assembly code to verify it)?

Thanks,

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jul 26, 2002, kaz Kojima <kkojima@rr.iij4u.or.jp> wrote:
[snip]
>> I've found a cause of many gij failures on SH port.
>> Interpreter takes JVM stack and local variables as variable
>> sized arrays:
> 
> Do you have a testcase that easily exposes the problem (even if one
> has to inspect the assembly code to verify it)?

OK. Here is a small example.
_Unwind_SjLj_Resume is called before allocating array aa. It seems
that the stack pointer is set higher than aa when the exception
handler invoked.

	kaz
--
-- aa.cc --
void foo (int);
void bar (int *) throw (int);
int a;

void
f (int max_stack)
{
  int aa[max_stack];
  int *sp = aa;

  try
    {
      bar (aa);
      return;
    }
  catch (int e)
    {
      foo (e);
      a = *sp;
    }
}

-- aa.s --
	.file	"aa.cc"
	.text
	.little
	.global	a
	.global	a
	.section	.bss
	.align 2
	.type	a, @object
	.size	a, 4
a:
	.zero	4
	.global	_Unwind_SjLj_Resume
	.global	__gxx_personality_sj0
	.global	_Unwind_SjLj_Register
	.global	_Unwind_SjLj_Unregister
	.text
	.align 5
	.global	_Z1fi
	.type	_Z1fi, @function
_Z1fi:
.LFB3:
	mov.l	r8,@-r15
.LCFI0:
	mov.l	r9,@-r15
.LCFI1:
	mov.l	r10,@-r15
.LCFI2:
	mov.l	r11,@-r15
.LCFI3:
	mov.l	r12,@-r15
.LCFI4:
	mov.l	r13,@-r15
.LCFI5:
	mov.l	r14,@-r15
.LCFI6:
	fmov.s	fr12,@-r15
.LCFI7:
	fmov.s	fr13,@-r15
.LCFI8:
	fmov.s	fr14,@-r15
.LCFI9:
	fmov.s	fr15,@-r15
.LCFI10:
	sts.l	pr,@-r15
.LCFI11:
	add	#-60,r15
.LCFI12:
	mov.l	.L13,r1
	mov	r15,r14
.LCFI13:
	mov.l	r1,@(24,r14)
	mov.l	.L14,r1
	mov.l	r1,@(28,r14)
	mov.l	.L15,r1
	mov.l	r1,@(36,r14)
	mov.l	.L16,r1
	mov.l	r4,@(44,r14)
	mov	r14,r4
	mov.l	r15,@(40,r14)
	jsr	@r1
	mov.l	r14,@(32,r14)
	mov.l	@(44,r14),r1
	shll2	r1
	mov.l	r15,@(48,r14)
	sub	r1,r15
	mov	#2,r1
	mov.l	r1,@(4,r14)
	mov	r15,r4
	mov.l	.L17,r1
	jsr	@r1
	mov.l	r15,@(52,r14)
.L10:
.L1:
	mov.l	.L18,r1
	mov	r14,r4
	jsr	@r1
	mov.l	@(48,r14),r15
	add	#60,r14
	mov	r14,r15
	lds.l	@r15+,pr
	fmov.s	@r15+,fr15
	fmov.s	@r15+,fr14
	fmov.s	@r15+,fr13
	fmov.s	@r15+,fr12
	mov.l	@r15+,r14
	mov.l	@r15+,r13
	mov.l	@r15+,r12
	mov.l	@r15+,r11
	mov.l	@r15+,r10
	mov.l	@r15+,r9
	rts	
	mov.l	@r15+,r8
	.align 5
.L8:
	mov	r1,r0
	cmp/eq	#1,r0
	bt/s	.L12
	mov	#-1,r1
.L6:
.L26:
	mov.l	@(56,r14),r4
	mov.l	r1,@(4,r14)
	mov.l	.L19,r1
	jsr	@r1
	nop
.L3:
	.align 5
.L12:
	mov.l	.L20,r0
	jsr	@r0
	mov.l	@(56,r14),r4
	mov	#1,r1
	mov.l	r1,@(4,r14)
	mov.l	@r0,r4
	mov.l	.L21,r1
	jsr	@r1
	nop
	mov.l	@(52,r14),r1
	mov.l	@r1,r2
	mov.l	.L22,r1
	mov.l	r2,@r1
	mov.l	.L24,r1
	jsr	@r1
	nop
	bra	.L10
	nop
	.align 5
.L9:
	mov.l	@(8,r14),r1
	mov.l	@(4,r14),r0
	cmp/eq	#1,r0
	mov.l	r1,@(56,r14)
	bt/s	.L8
	mov.l	@(12,r14),r1
.L4:
	mov.l	.L24,r1
	jsr	@r1
	nop
	bra	.L26
	mov	#-1,r1
.L25:
	.align 2
.L13:
	.long	__gxx_personality_sj0
.L14:
	.long	.LLSDA3
.L15:
	.long	.L9
.L16:
	.long	_Unwind_SjLj_Register
.L17:
	.long	_Z3barPi
.L18:
	.long	_Unwind_SjLj_Unregister
.L19:
	.long	_Unwind_SjLj_Resume
.L20:
	.long	__cxa_begin_catch
.L21:
	.long	_Z3fooi
.L22:
	.long	a
.L24:
	.long	__cxa_end_catch
.LFE3:
	.size	_Z1fi, .-_Z1fi
	.section	.gcc_except_table,"aw",@progbits
	.align 2
.LLSDA3:
	.byte	0xff
	.byte	0x0
	.uleb128 .LLSDATT3-.LLSDATTD3
.LLSDATTD3:
	.byte	0x1
	.uleb128 .LLSDACSE3-.LLSDACSB3
.LLSDACSB3:
	.uleb128 0x0
	.uleb128 0x0
	.uleb128 0x1
	.uleb128 0x1
.LLSDACSE3:
	.byte	0x1
	.byte	0x0
	.align 2
	.long	_ZTIi
.LLSDATT3:
	.text
	.ident	"GCC: (GNU) 3.3 20020804 (experimental)"

Re: [PATCH/RFA] libjava: SH support

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz> I've found a cause of many gij failures on SH port.
kaz> Interpreter takes JVM stack and local variables as variable
kaz> sized arrays:

Alexandre> Do you have a testcase that easily exposes the problem
Alexandre> (even if one has to inspect the assembly code to verify
Alexandre> it)?

kaz> OK. Here is a small example.

What is the status of this?
Perhaps opening a PR would make sense, so we can track it?

Tom

Re: [PATCH/RFA] libjava: SH support

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> Alexandre> Do you have a testcase that easily exposes the problem
> Alexandre> (even if one has to inspect the assembly code to verify
> Alexandre> it)?
> 
> kaz> OK. Here is a small example.
> 
> What is the status of this?
> Perhaps opening a PR would make sense, so we can track it?

Yet open or partially analyzed for me. It seems to be a generic
problem for targets using the sjlj exception.
If it isn't a known problem, I'd like to create a PR.

Regards,
	kaz