Skip to content
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

Bridj problems passing double under armhf #525

Closed
jonhare opened this issue Sep 16, 2014 · 4 comments
Closed

Bridj problems passing double under armhf #525

jonhare opened this issue Sep 16, 2014 · 4 comments

Comments

@jonhare
Copy link

@jonhare jonhare commented Sep 16, 2014

Hi Olivier,

I've had a few reports of strange issues with the OpenIMAJ webcam library not working properly on linux boards using the armhf ABI (@sarxos also has a load of issues with his webcam project where the openimaj library is failing under armhf - see e.g. sarxos/webcam-capture#244).

I spent the day debugging, and have narrowed the problem down to the passing of double values. For some reason, if you try to pass a double value as a function/method argument from the Java side to the native side, the value will not be correctly passed, and the stack will be corrupted (noticeable in particular through subsequent arguments not having the correct values either, before the ensuing SEGFAULT).

I've made a very simple test case here: http://users.ecs.soton.ac.uk/jsh2/testcase.tgz
The test case contains a native library (sources in src/main/cpp) with a single method that takes a single double and prints it; the java code just wraps the native lib and calls the function with the double value 101.101. What we'd expect to happen is for 101.101000 to be printed, but instead we get 0.0. I've tested under an older armel JVM (using bridj 0.6.3-SNAPSHOT), and the code works as expected, so this definitely appears to be a specific problem with the armhf abi.

I don't know enough about the internals of bridj, but I wonder if the problem is related to the use of the wrong registers for passing the values (see this thread https://groups.google.com/forum/#!topic/avian/8nz4JZEPwZs, which was what got me looking at the double value in the first place).

Let me know if there's anything else I can do to help debug.

Jon

@jonhare
Copy link
Author

@jonhare jonhare commented Sep 16, 2014

After more digging, I came across this in the dyncall manual: "It is important to note, that dyncall supports the ARM architecture calling convention variant {\bf with floating point hardware disabled} (meaning that the FPA and the VFP (scalar mode) procedure call standards are not supported)."

Which kind of implies that modern (full hardfp as opposed to soft and softfp) arm linux builds won't work with dyncall at present...

@ochafik
Copy link
Member

@ochafik ochafik commented Sep 19, 2014

Hey @jonhare , thanks for digging this out!
I'll try to reach out to the dyncall guys, but we can also try and patch something ourselves (see Debian's hard-float page for a start, and some general info about vfp registers, and a vfp programming guide)

@ochafik
Copy link
Member

@ochafik ochafik commented Sep 21, 2014

Quick update: it looks like dyncall does support hard-float, but... not dyncallback (the part of dyncall that allows creating dynamic callbacks, which BridJ uses heavily). I'm having a look at how hard it would be to adding that support :-)

@ochafik
Copy link
Member

@ochafik ochafik commented Mar 18, 2015

This issue was moved to nativelibs4java/BridJ#40

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants