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

[Bob Vandette]

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 __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
>>> 
>