jdk9-arm3264 libjvm.so link error with arm-sflt

[Simon Nash]

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 
>>> __aeabi_xxxx_glibc 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, __aeabi_fadd_glibc takes two floats and 
>> returns double
>> but __aeabi_fadd 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 f64_add 
>> 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, __aeabi_fadd_glibc
is defined in hotspot/src/cpu/arm/vm/assembler_arm_32.hpp as

extern double __aeabi_fadd_glibc(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 __aeabi_fsub_glibc
in assembler_arm_32.hpp is wrong as well.

  Simon

> /* GLIBC Equivalent Soft-Float Implementations */
> #ifndef JDK_BUILD
> double __aeabi_dadd_glibc( double a, double b )
> #else
> double __aeabi_dadd( 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 JDK_BUILD
> double __aeabi_dsub_glibc( double a, double b )
> #else
> double __aeabi_dsub( 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 JDK_BUILD
> float __aeabi_fadd_glibc( float a, float b ) 
> #else
> float __aeabi_fadd( float a, float b )
> #endif
> {
>     ufloat32 f32a, f32b, f32result;
>     
> 
>     f32a.f = a;
>     f32b.f = b;
> 
>     f32result.i32 = float32_add(f32a.i32, f32b.i32);
>     return (f32result.f);
> }
> 
> #ifndef JDK_BUILD
> float __aeabi_fsub_glibc( float a, float b )
> #else
> float __aeabi_fsub( float a, float b )
> #endif
> {
>     ufloat32 f32a, f32b, f32result;
> 
>     f32a.f = a;
>     f32b.f = b;
> 
>     f32result.i32 = float32_sub(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/c1_LIRGenerator_arm.o: 
>>>> In function `GrowableArray<Instruction*>::at_put_grow(int, 
>>>> Instruction* const&, Instruction* const&)':
>>>> /sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: 
>>>> undefined reference to `__aeabi_fadd_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: 
>>>> undefined reference to `__aeabi_dadd_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: 
>>>> undefined reference to `__aeabi_fsub_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/share/vm/utilities/growableArray.hpp:291: 
>>>> undefined reference to `__aeabi_dsub_glibc'
>>>> /sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/c1_Runtime1_arm.o: 
>>>> In function `Runtime1::pd_name_for_address(unsigned char*)':
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1_Runtime1_arm.cpp:1220: 
>>>> undefined reference to `__aeabi_fadd_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1_Runtime1_arm.cpp:1220: 
>>>> undefined reference to `__aeabi_fsub_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1_Runtime1_arm.cpp:1220: 
>>>> undefined reference to `__aeabi_dadd_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/c1_Runtime1_arm.cpp:1220: 
>>>> undefined reference to `__aeabi_dsub_glibc'
>>>> /sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/templateTable_arm.o: 
>>>> In function `TemplateTable::fop2(TemplateTable::Operation)':
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTable_arm.cpp:1718: 
>>>> undefined reference to `__aeabi_fadd_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTable_arm.cpp:1718: 
>>>> undefined reference to `__aeabi_fsub_glibc'
>>>> /sd1/jdk9-arm3264/build/softfp/hotspot/variant-server/libjvm/objs/templateTable_arm.o: 
>>>> In function `TemplateTable::dop2(TemplateTable::Operation)':
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTable_arm.cpp:1761: 
>>>> undefined reference to `__aeabi_dadd_glibc'
>>>> /sd1/jdk9-arm3264/hotspot/src/cpu/arm/vm/templateTable_arm.cpp:1761: 
>>>> undefined reference to `__aeabi_dsub_glibc'
>>>> 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-20120426_linux/bin 
>>>> \
>>>> --with-sys-root=/sd1/linaro/gcc-linaro-arm-linux-gnueabi-2012.04-20120426_linux/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.0_25 \
>>>> 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 __aeabi_fadd_glibc defined? 
>>>>  I have found
>>>> __aeabi_fadd but I have not been able to find __aeabi_fadd_glibc.
>>>>
>>>> Simon
>>
>