-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong ffi_type for unsigned numbers causes bugs on some platforms #1435
Comments
This problem can be fixed by correctly using As an experiment, I have re-compiled JNA with that line changed to To properly fix this, the information about the signedness would somehow need to be passed to the Just to be clear, I am aware that this behavior is documented here under NOTES. However, I believe it should be changed because as a user of the library, I would expect it to behave correctly out of the box in a situation like this. I think it should not depend on the target architecture and JNA's assumptions about storing of unsigned numbers, and a possible mismatch of the two. The experiment with the custom build of JNA is available in the
|
Am I missing something obvious here? To my understanding the native interface is determined from the headerfiles and the platform ABI. The caller pushes the arguments for the function onto the stack/places them into the right registers and jumps to the target function. The callee then reads them from these places. When you say it works with different optimiziation levels, then to my understanding the ABI of the called function changes and this does not sound like sane behavior for a compiler. I would then ask how runtime linking would work, as that will then also break. |
It's not entirely obvious, but not too difficult either. The problem is in the "caller pushes the arguments for the function onto the stack/places them into the right registers" part. This pushing of arguments is implemented using libffi. Libffi itself handles that correctly, provided the argument types passed to libffi are correct. Which is not the case for unsigned integers! This is the line I am talking about. Notice that it always uses Line 519 in ca465ee
I am assuming that in most cases, this naive approach works fine, but it is in fact relying on undefined behavior. And in my case, that breaks it. The compiler optimizations are actually correct here, which is proven by the fact that changing the line to |
Provide complete information about the problem
5.11.0@aar
ART @ Android 11
Android 11
arm64-v8a, x86_64, possibly more
Output of
clang --version
:Compiler Android (7019983 based on r365631c3) clang version 9.0.9 (https://android.googlesource.com/toolchain/llvm-project a2a1e703c0edb03ba29944e529ccbf457742737b) (based on LLVM 9.0.9svn).
Function argument of type
unsigned short
passed by JNA to native code does not behave correctly when the code is compiled with optimizations enabled. The is caused by the fact that LLVM is counting on the argument being stored in straight format (as it should be) instead of two's complement.Minimal reproducible example available here.
The
hello
function in the following code should returntrue
, but returnsfalse
.Log output with optimizations disabled:
Log output with optimizations enabled:
The text was updated successfully, but these errors were encountered: