jdk9-arm3264 libjvm.so link error with arm-sflt
Simon Nash
simon at cjnash.com
Wed Dec 7 10:31:40 UTC 2016
On 06/12/2016 19:54, Bob Vandette wrote:
>> On Dec 6, 2016, at 2:38 PM, Simon Nash <simon at cjnash.com> wrote:
>>
>> On 07/11/2016 13:00, 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.
>> I have used a modified version of this code to solve the problem with
>> building a soft-float version of libjvm.so. This has enabled me to complete
>> an ARMv5 soft-float build of the client JRE, which seems to be working OK.
>> Many thanks for your help with this.
>>
>> I have tried to use the alternative JDK_BUILD version of the wrapper code
>> to build JDK native shared libraries with accurate versions of these four
>> functions. This is failing because the linker is pulling in overlapping code
>> from libgcc.a and producing multiple definition errors for these symbols.
>>
>> For example, libmanagement_ext.so depends on both __aeabi_dadd and
>> __aeabi_ul2d. The linker brings in __aeabi_dadd from my wrapper, then
>> tries to resolve __aeabi_ul2d by bringing in _arm_addsubsf3.o from libgcc.a.
>> Because _arm_addsubsf3.o defines __aeabi_dadd as well as __aeabi_ul2d,
>> there are multiple definitions for __aeabi_dadd and the link fails.
>>
>> Perhaps I have misunderstood the purpose of the JDK_BUILD version of this
>> wrapper code. If it is intended to be included in JDK native libraries such
>> as libmanagement_ext.so, how do you solve the multiple definition problem?
>
> In JDK8, we built the soft-float library including the wrapper into a single archive and
> added this library to the link of each native library. We add -z muldefs to avoid
> the muliply defined errors.
>
> sflt_glibc_jdk.a -Xlinker -z -Xlinker muldefs
>
Thanks for the pointer to -z muldefs. With this change, I have been able to
build the JDK libraries with accurate floating-point support.
While setting up a configuration to do this, I found a problem in the
configure script. On line 1286 of common/autoconf/flags.m4, the line
$2JDKLIB_LIBS="-ljava -ljvm"
should be changed to
$2JDKLIB_LIBS="[$]$2JDKLIB_LIBS -ljava -ljvm"
as is done for the similar case of JVM_LIBS in line 1297 and following.
This allows the user to pass the floating-point library to the configure
script by setting the JDKLIB_LIBS variable.
I would also be inclined to remove line 1262:
$2JDKLIB_LIBS=""
so that any user setting of JDKLIB_LIBS is preserved when using the
Microsoft toolchain.
Should I submit a patch for this?
Simon
> Bob.
>
>> 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
>
>
More information about the aarch32-port-dev
mailing list