Tom Tromey <t...@tromey.com> writes: > >>>>> "Matthew" == Matthew Fortune <matthew.fort...@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