jdk9-arm3264 libjvm.so link error with arm-sflt
Simon Nash
simon at cjnash.com
Tue Dec 6 19:38:04 UTC 2016
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?
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