This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] Fix FFI return type for closures in the java interpreter
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: "java-patches at gcc dot gnu dot org" <java-patches at gcc dot gnu dot org>, "'gcc-patches at gcc dot gnu dot org' (gcc-patches at gcc dot gnu dot org)" <gcc-patches at gcc dot gnu dot org>, "per at bothner dot com" <per at bothner dot com>, "aph at redhat dot com" <aph at redhat dot com>, Aurelien Jarno <aurelien at aurel32 dot net>
- Date: Tue, 28 Jun 2016 15:29:56 +0000
- Subject: RE: [PATCH] Fix FFI return type for closures in the java interpreter
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023537E45FD9F at HHMAIL01 dot hh dot imgtec dot org> <87shvyib1n dot fsf at tromey dot com> <8760stviqj dot fsf at tromey dot com>
Tom Tromey <tom@tromey.com> writes:
> >>>>> "Matthew" == Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Matthew> I've identified a latent bug in the java interpreter that affects MIPS
> Matthew> n32 and n64 ABIs both little and big endian and, I presume, any 64-bit
> Matthew> big endian target with int as 32-bit.
> [...]
>
> Matthew> libjava/
> Matthew> * interpret-run.cc: Use ffi_arg for FFI integer return types.
> Matthew> libjava/testsuite/
> Matthew> * libjava.jar/arraysort.java: New file.
> Matthew> * libjava.jar/arraysort.jar: New file.
> Matthew> * libjava.jar/arraysort.out: New file.
> Matthew> * libjava.jar/arraysort.xfail: New file.
>
> Tom> This is ok.
>
> It occurred to me that this might not be correct on platforms using the
> Java raw API; which I think is just x86.
>
> I'm actually not sure -- I don't remember (if I ever knew) if the raw
> API has the same return-value promotion rules as the ordinary API.
>
> Could you check? I think a -m32 build ought to show it. Maybe your
> x86-64 build already did this?
I'm not sure this will matter if the only arch is x86 as ffi_arg will be
32-bit anyway there. There would need to be a 64bit arch using the raw
api. I don't really understand what the raw api is, the references to it
in the code seemed cryptic.
I can do a -m32 test anyway, I only did x86_64 as I don't think that
32-bit architectures will be affected at all.
> Matthew> I mentioned in my earlier post about a possible similar issue in the
> Matthew> lang/reflect/natVMProxy.cc code (unbox function) by code inspection. I
> Matthew> don't know how to trigger this code but perhaps someone can advise.
>
> It's a bit complicated, and it's been a while since I looked at any of
> this, but I think what you want to do is make an InvocationHandler that
> handles some method returning "int" (maybe hashCode would work), then
> make a Proxy class that wraps it. Then, make an instance of the proxy
> class and call the method.
Thanks for the pointers, a bit of googling got me to the right code. I can
confirm that my guess was right and the same bug exists in the natVMProxy.cc
code. It will break for all big endian targets when using types smaller than
a word. I have only proved the bug exists so far but not tried a fix.
Thanks,
Matthew