jdk9-arm3264 libjvm.so link error with arm-sflt (original) (raw)

Bob Vandette bob.vandette at oracle.com
Mon Nov 7 15:37:54 UTC 2016

I don’t know why we ended up using double returns for the float functions but it’s been that way since this code was first implemented. The definition is wrong but it’s possible that it doesn’t really matter. We explicitly call these functions via call_VM_leaf and manually manipulate the return registers.

I did a patch in JDK8 that makes the soft-float2b library optional. This patch never made its way into JDK9. It still has the double return type issue but only if you use the external library.

Bob.

On Nov 7, 2016, at 9:08 AM, Simon Nash <simon at cjnash.com> wrote:

Bob Vandette wrote:

On Nov 6, 2016, at 1:07 PM, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com>> wrote:

Bob Vandette wrote: In the soft-float binaries we’ve distributed in the past, we linked our binary against an external library. In order to achieve Java level floating point accuracy (and pass the TCK), you’ll need to do the same. Here’s the library that we used: http://www.jhauser.us/arithmetic/SoftFloat.html _We modify this library to map their fadd,dadd,fsub,dsub functions to aeabixxxxglibc function names. You should be able to temporarily work around your link problems by removing the glibc from the references in the hotspot and jdk sources. There are only a few files that are impacted. The problem stems from the fact that the normal glibc functions prefer speed over accuracy. The accuracy difference is extremely minimal but we fail the TCK for a few tests causing us to use this extra library. Hope this help, Bob. Thanks very much! I thought about removing the glibc suffix but the signatures _are different. For example, aeabifaddglibc takes two floats and returns double _but aeabifadd takes two floats and returns float. From a quick look at the Hauser library, there is a similar signature mismatch there as well, so I presume it would be necessary to write a small wrapper function to convert both float32 arguments to float64 and then call the f64add function in the library. If I have misunderstood this, please correct my assumption. Here’s the wrapper code we used with softfloat-2b. Notice that we build two different libraries. The JDK functions override the normal entry point but the hotspot version uses a unique name. This was done to allow the normal float/double operations done by the VM to use the faster inlined glibc functions but the functions called during bytecode processing use the accurate ones. _Thanks, this is very helpful. In the jdk9-arm3264 source, aeabifaddglibc is defined in hotspot/src/cpu/arm/vm/assemblerarm32.hpp as _extern double aeabifaddglibc(float, float); The double return type with float arguments was throwing me because this is different from all the floating-point libraries I have seen. The code you have posted confirms that the correct signature has a float return type, _which makes the wrapping much simpler. The signature for aeabifsubglibc in assemblerarm32.hpp is wrong as well. Simon /* GLIBC Equivalent Soft-Float Implementations */ #ifndef JDKBUILD _double aeabidaddglibc( double a, double b ) #else _double aeabidadd( double a, double b ) #endif { flag aSign, bSign; float64 f64a, f64b; f64a.d = a; f64b.d = b; aSign = extractFloat64Sign( f64a ); bSign = extractFloat64Sign( f64b ); if ( aSign == bSign ) { return addFloat64Sigs( f64a, f64b, aSign ).d; } else { return subFloat64Sigs( f64a, f64b, aSign ).d; } } #ifndef JDKBUILD _double aeabidsubglibc( double a, double b ) #else _double aeabidsub( double a, double b ) #endif { flag aSign, bSign; float64 f64a, f64b; f64a.d = a; f64b.d = b; aSign = extractFloat64Sign( f64a ); bSign = extractFloat64Sign( f64b ); if ( aSign == bSign ) { return subFloat64Sigs( f64a, f64b, aSign ).d; } else { return addFloat64Sigs( f64a, f64b, aSign ).d; } } #ifndef JDKBUILD _float aeabifaddglibc( float a, float b ) #else _float aeabifadd( float a, float b ) #endif { ufloat32 f32a, f32b, f32result; f32a.f = a; f32b.f = b; f32result.i32 = float32add(f32a.i32, f32b.i32); return (f32result.f); } #ifndef JDKBUILD _float aeabifsubglibc( float a, float b ) #else _float aeabifsub( float a, float b ) #endif { ufloat32 f32a, f32b, f32result; f32a.f = a; f32b.f = b; f32result.i32 = float32sub(f32a.i32, f32b.i32); return (f32result.f); } Bob. Best regards, Simon

On Nov 6, 2016, at 11:06 AM, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com>> wrote:

I am trying to build the current jdk9-arm3264 source for arm-sflt and I am getting some link errors from libjvm.so as follows: _/sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/c1LIRGeneratorarm.o: In function GrowableArray<Instruction*>::atputgrow(int, Instruction* const&, Instruction* const&)':_ _/sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: undefined reference to aeabifaddglibc' _/sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: undefined reference to _aeabidaddglibc'_ _/sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: undefined reference to aeabifsubglibc' /sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: undefined reference to _aeabidsubglibc'_ _/sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/c1Runtime1arm.o: In function Runtime1::pdnameforaddress(unsigned char*)': _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1Runtime1arm.cpp:1220: undefined reference to _aeabifaddglibc'_ _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1Runtime1arm.cpp:1220: undefined reference to aeabifsubglibc' _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1Runtime1arm.cpp:1220: undefined reference to _aeabidaddglibc'_ _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1Runtime1arm.cpp:1220: undefined reference to aeabidsubglibc' _/sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/templateTablearm.o: In function TemplateTable::fop2(TemplateTable::Operation)':_ _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTablearm.cpp:1718: undefined reference to aeabifaddglibc' /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTablearm.cpp:1718: undefined reference to _aeabifsubglibc'_ _/sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/templateTablearm.o: In function TemplateTable::dop2(TemplateTable::Operation)': _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTablearm.cpp:1761: undefined reference to _aeabidaddglibc'_ _/sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTablearm.cpp:1761: undefined reference to aeabidsubglibc' collect2: error: ld returned 1 exit status I am using a soft-float Linaro cross-compiler to do the build. Here is my configure command: _bash ./configure --with-jdk-variant=normal --with-jvm-variants=server --with-abi-profile=arm-sflt --with-conf-name=softfp _ --with-debug-level=release --disable-warnings-as-errors --with-extra-cflags=-D_SOFTFP --openjdk-target=arm-linux-gnueabi _ _--with-tools-dir=/sd1/linaro/gcc-linaro-arm-linux-gnueabi-2012.04-20120426linux/bin _ _--with-sys-root=/sd1/linaro/gcc-linaro-arm-linux-gnueabi-2012.04-20120426linux/arm-linux-gnueabi/libc _ _--with-cups=/sd1/armel/cups --with-freetype=/sd1/armel/freetype2 --with-alsa=/sd1/armel/alsa _ _--x-includes=/sd1/armel/X11/include --x-libraries=/sd1/armel/X11/lib _ _--disable-freetype-bundling --disable-hotspot-gtest --with-boot-jdk=/sd1/java/jdk1.8.025 _ _CC=arm-linux-gnueabi-gcc CXX=arm-linux-gnueabi-g++ CPP=arm-linux-gnueabi-cpp CXXCPP=arm-linux-gnueabi-cpp _ LIBS="-Wl,-rpath-link /sd1/armel/freetype2/lib -Wl,-rpath-link /sd1/armel/X11/lib" _Where are the missing functions such as aeabifaddglibc defined? I have found __aeabifadd but I have not been able to find aeabifaddglibc. Simon

More information about the aarch32-port-dev mailing list