This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]