This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH/RFC] Enable java on sh64-linux
- From: "David Daney" <ddaney at avtrex dot com>
- To: "Kaz Kojima" <kkojima at rr dot iij4u dot or dot jp>,<tromey at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>,<java-patches at gcc dot gnu dot org>,<joern dot rennecke at superh dot com>,<aoliva at redhat dot com>
- Date: Mon, 27 Sep 2004 20:54:12 -0700
- Subject: RE: [PATCH/RFC] Enable java on sh64-linux
Kaz Kojime wrote:
>Tom Tromey <tromey@redhat.com> wrote:
>>>> The appended patch is to enable java on sh64-*-linux-gnu target.
>>>> It only affects sh*-linux* targets anyway, and essentially affects
>>>> sh64-linux only.
>>
>> This libjava configury bits look fine. Someone else will have to
>> comment on the rest.
>
>Thanks. I'd like to wait comments for libffi and toplevel configury
>part.
>>>> FAIL: Array_3 execution - source compiled test
>>>> FAIL: Array_3 execution - gij test
>>>> FAIL: Array_3 execution - bytecode->native test
>>>> FAIL: Array_3 -O3 execution - source compiled test
>>>> FAIL: Array_3 execution - gij test
>>>> FAIL: Array_3 -O3 execution - bytecode->native test
>>
>> This suggests that the SEGV -> NullPointerException code is not
>> working properly. I see this port uses dwarf2-signal.h, so perhaps
>> MD_FALLBACK_FRAME_STATE_FOR isn't working properly?
>
>Looking closely the Array_3 testcase, I've found that the problematic
>try block has only one instruction:
>
>.LEHB1:
> ld.l r1, 4, r1
>.LEHE1:
>
>and if I insert an additional java code after the code which generates
>SEGV in the try block, the error goes away. It looks there is something
>wrong in judging whether PC is in the try block or not. I'll see what
>happens in detail. Thanks for your suggestion.
Looks like you have to increment the PC value (in the stored register area) so
that it is pointing after the faulting instruction.
MIPS and x86 do this (as I imagine do others) in ????-signal.h.
David Daney