{{ message }}

# Bridj problems passing double under armhf #525

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

# Bridj problems passing double under armhf#525

opened this issue Sep 16, 2014 · 4 comments
Labels

### 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 The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.

### 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 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 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 :-)
added a commit that referenced this issue Sep 22, 2014
 BridJ/dyncall: simplify arm32 dyncall code (use one fldmiad instructi… 
 e78965b 
…on instead of many flds), and draft support for VFP in dyncallback (issue #525)
mentioned this issue Feb 24, 2015
mentioned this issue Mar 18, 2015

### ochafik commented Mar 18, 2015

 This issue was moved to nativelibs4java/BridJ#40
closed this Mar 18, 2015
added a commit to onozaty/shared-camera-websocket that referenced this issue Jan 21, 2018
 Raspberry Pi で bridj がらみで問題があるため、jarを対応済みのものに差し替え 
 d6c2590 
nativelibs4java/nativelibs4java#525