HSAIL unit tests fail when Okra library fails to load
Tim Bell
tim.bell at oracle.com
Tue Jun 3 15:31:13 UTC 2014
Ah, I see. Thanks. So RPM (or equivalent) is the authority to consult
on Linux, at least until we get to JDK 9 and start using your devkits to
build.
Tim
On 06/03/14 14:58, Erik Joelsson wrote:
> I don't think they are conflicting. /lib/libc.so.6 is part of the
> package glibc-2.8-3.
>
> /Erik
>
> On 2014-06-03 16:52, Tim Bell wrote:
>> That's puzzling - how does rpm square with what ldd is reporting?
>> Is glibc loaded dynamically, in which case my experiments are missing
>> the point...
>>
>> hostname
>> sc11137352
>>
>> /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java -version
>> java version "1.8.0"
>> Java(TM) SE Runtime Environment (build 1.8.0-b132)
>> Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode)
>>
>>
>> ldd /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java
>> linux-gate.so.1 => (0x00110000)
>> libpthread.so.0 => /lib/libpthread.so.0 (0x009aa000)
>> libjli.so =>
>> /opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/../lib/i386/jli/libjli.so
>> (0x00111000)
>> libdl.so.2 => /lib/libdl.so.2 (0x009a3000)
>> libc.so.6 => /lib/libc.so.6 (0x0080d000)
>> /lib/ld-linux.so.2 (0x007ed000)
>>
>> Tim
>>
>> On 06/03/14 08:14, Erik Joelsson wrote:
>>> And according to rpm, the version is:
>>>
>>> $ rpm -q glibc
>>> glibc-2.8-3.x86_64
>>>
>>> /Erik
>>>
>>> On 2014-06-03 03:01, Tim Bell wrote:
>>>> Hi - catching up on my email backlog:
>>>>
>>>>> Not sure what glibc version that is, though.
>>>>
>>>> For Linux builds, others on build-dev at openjdk.java.net are more
>>>> knowledgeable about glibc used in different JDK releases.
>>>>
>>>> Hmmm - these README-builds.html files do not mention a specific
>>>> glibc version:
>>>>
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/raw-file/tip/README-builds.html
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk7u/jdk7u-dev/raw-file/tip/README-builds.html
>>>>
>>>>
>>>> I ran a little test on one of our Fedora 9 build/test systems:
>>>>
>>>> uname -a
>>>> Linux sc11137352 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT
>>>> 2008 i686 i686 i386 GNU/Linux
>>>>
>>>> gcc -v
>>>> Using built-in specs.
>>>> Target: i386-redhat-linux
>>>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>>>> --infodir=/usr/share/info
>>>> --with-bugurl=http://bugzilla.redhat.com/bugzilla
>>>> --enable-bootstrap --enable-shared --enable-threads=posix
>>>> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
>>>> --disable-libunwind-exceptions
>>>> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
>>>> --enable-java-awt=gtk --disable-dssi --enable-plugin
>>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
>>>> --enable-libgcj-multifile --enable-java-maintainer-mode
>>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
>>>> --disable-libjava-multilib --with-cpu=generic
>>>> --build=i386-redhat-linux
>>>> Thread model: posix
>>>> gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
>>>>
>>>> cat -n hw.c
>>>> 1 #include <stdio.h>
>>>> 2 int main() {
>>>> 3 printf("Hello world\n");
>>>> 4 }
>>>>
>>>> gcc -o hw hw.c
>>>>
>>>> ./hw
>>>> Hello world
>>>>
>>>> ldd ./hw
>>>> linux-gate.so.1 => (0x00110000)
>>>> libc.so.6 => /lib/libc.so.6 (0x0080d000)
>>>> /lib/ld-linux.so.2 (0x007ed000)
>>>>
>>>>
>>>> Hope this helps-
>>>>
>>>> Tim
>>>>
>>>>
>>>> On 05/23/14 00:13, Christian Thalinger wrote:
>>>>>
>>>>> On May 22, 2014, at 5:04 PM, Doug Simon <doug.simon at oracle.com
>>>>> <mailto:doug.simon at oracle.com>> wrote:
>>>>>
>>>>>>
>>>>>> On May 23, 2014, at 12:44 AM, Deneau, Tom <tom.deneau at amd.com
>>>>>> <mailto:tom.deneau at amd.com>> wrote:
>>>>>>
>>>>>>> Doug --
>>>>>>>
>>>>>>> What glibc does Hotspot build against?
>>>>>>
>>>>>> I’m not sure - Christian may know (or know who knows).
>>>>>
>>>>> Looking at some wiki pages JDK 8 is building on:
>>>>>
>>>>> Fedora 9 / GCC 4.3
>>>>>
>>>>> Not sure what glibc version that is, though. Tim Bell is the
>>>>> right guy to ask.
>>>>>
>>>>>>
>>>>>> -Doug
>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>> Sent: Thursday, May 22, 2014 5:40 PM
>>>>>>>> To: Caspole, Eric
>>>>>>>> Cc: Deneau, Tom; Bernhard Urban
>>>>>>>> Subject: Re: HSAIL unit tests fail when Okra library fails to load
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 22, 2014, at 11:19 PM, Eric Caspole
>>>>>>>> <eric.caspole at amd.com <mailto:eric.caspole at amd.com>> wrote:
>>>>>>>>
>>>>>>>>> Hi Doug,
>>>>>>>>> Do you think it is worth it to build the built in Okra
>>>>>>>>> simulator with
>>>>>>>> an older glibc to help avoid this problem? What is the oldest
>>>>>>>> distro you
>>>>>>>> intend to support with Graal?
>>>>>>>>
>>>>>>>> In theory we should support whatever HotSpot does although in
>>>>>>>> practice
>>>>>>>> we only need it to work on OSes for which we build distributions.
>>>>>>>>
>>>>>>>> However, I think it's fine (for now at least) if we just cleanly
>>>>>>>> ignore/short-circuit the HSAIL unit tests in question on
>>>>>>>> platforms with
>>>>>>>> an older glibc.
>>>>>>>>
>>>>>>>> -Doug
>>>>>>>>
>>>>>>>>> On 05/22/2014 07:33 AM, Doug Simon wrote:
>>>>>>>>>> Hi Tom, Eric,
>>>>>>>>>>
>>>>>>>>>> We're in the process of making GraalVM binary builds that
>>>>>>>>>> work on
>>>>>>>> Oracle Linux 6.5 which has an old version of glibc (GLIBC
>>>>>>>> 2.12). While
>>>>>>>> testing this build, the HSAIL tests that use the Okra library fail
>>>>>>>> because libokra_x86_64.so is built against a version of GLIBC
>>>>>>>> later than
>>>>>>>> 2.12. However, the failure message is very confusing. For example:
>>>>>>>>>>
>>>>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest
>>>>>>>>>> GraalJUnitCore
>>>>>>>>>> JUnit version 4.11
>>>>>>>>>> .E
>>>>>>>>>> Time: 0.77
>>>>>>>>>> There was 1 failure:
>>>>>>>>>> 1)
>>>>>>>> test(com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest)
>>>>>>>>
>>>>>>>>>> java.lang.NoClassDefFoundError: Could not initialize class
>>>>>>>> com.amd.okra.OkraContext
>>>>>>>>>> at
>>>>>>>> com.oracle.graal.compiler.hsail.test.infra.KernelTester.<init>(KernelTes
>>>>>>>>
>>>>>>>> ter.java:129)
>>>>>>>>>> at
>>>>>>>> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.<init>(Graa
>>>>>>>>
>>>>>>>> lKernelTester.java:63)
>>>>>>>>>> at
>>>>>>>> com.oracle.graal.compiler.hsail.test.SingleExceptionTestBase.<init>(Sing
>>>>>>>>
>>>>>>>> leExceptionTestBase.java:32)
>>>>>>>>>> at
>>>>>>>> com.oracle.graal.compiler.hsail.test.Vec3ObjStreamClassCastTest.<init>(V
>>>>>>>>
>>>>>>>> ec3ObjStreamClassCastTest.java:31)
>>>>>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>>>>>>>> Method)
>>>>>>>>>> at
>>>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
>>>>>>>>
>>>>>>>> ccessorImpl.java:62)
>>>>>>>>>> at
>>>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
>>>>>>>>
>>>>>>>> tructorAccessorImpl.java:45)
>>>>>>>>>> at
>>>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408)
>>>>>>>>>> at
>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunn
>>>>>>>>
>>>>>>>> er.java:195)
>>>>>>>>>> at
>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4
>>>>>>>>
>>>>>>>> ClassRunner.java:244)
>>>>>>>>>>
>>>>>>>>>> Can you please make sure the HSAIL test harness recognizes a
>>>>>>>>>> failure
>>>>>>>> to load the Okra library (preferably issuing a message if it's
>>>>>>>> for any
>>>>>>>> other reason than the library not being available). One way to
>>>>>>>> trigger
>>>>>>>> this is to fake a bad library:
>>>>>>>>>>
>>>>>>>>>> $ mkdir -p resources/okra/Linux
>>>>>>>>>> $ echo "bad" >resources/okra/Linux/libokra_x86_64.so
>>>>>>>>>> $ jar uvf lib/okra-1.9-with-sim.jar
>>>>>>>> resources/okra/Linux/libokra_x86_64.so
>>>>>>>>>> $ mx --vm server unittest Vec3ObjStreamClassCastTest
>>>>>>>>>>
>>>>>>>>>> -Doug
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the build-dev
mailing list