Please review correction of regression test Test6929067
Pavel Tisnovsky
ptisnovs at redhat.com
Mon May 9 02:30:29 PDT 2011
David Holmes wrote:
> Pavel Tisnovsky said the following on 05/06/11 19:57:
>> David Holmes wrote:
>>> Pavel,
>>>
>>> I'm a bit confused about this test with regards to how it is supposed to
>>> work and what combinations of 32-bit and 64-bit are expected. It seems
>>> to me that if you run this on a 64-bit platform then it expects to find
>>> that TESTJAVA is a 64-bit VM, which may not be the case.
>>>
>>> I also don't understand this part:
>>>
>>> ! gcc ${COMP_FLAG} -o invoke \
>>> ! -L${TESTJAVA}/jre/lib/${ARCH}/client \
>>> ! -L${TESTJAVA}/jre/lib/${ARCH}/server \
>>> ! -ljvm -lpthread -I${TESTJAVA}/include -I${TESTJAVA}/include/linux
>>> invoke.c
>>>
>>> does this assume/expect that client will be found on 32-bit and server
>>> only on 64-bit because we don't presently ship 64-bit client? In terms
>>> of exported symbols I believe the two should be the same. Will gcc
>>> complain if it encounters a 64-bit lib if compiling with -m32 and
>>> vice-versa?
>>
>> Hi David,
>>
>> AFAIK gcc does not care if client and/or server libraries is found. When
>> .../client/ directory does not exists it simply uses libraries from
>> .../server/ directory. I'm not sure in which case gcc could find 64-lib
>> using -m32 - on Solaris? (To be honest I have not tested this test on
>> Solaris)
>
> Solaris behaviour is not relevant as the test trivially declares success
> on Solaris and Windows.
>
> But I'm very unclear on the behaviour on Linux. As I said it seems to
> only expect to find a 64-bit JVM on a 64-bit capable platform.
Hi David,
thank you for your response. I'll rather check this test second time on
all possible combinations of platform+JVM.
Cheers,
Pavel
>
> David
>
>> Pavel
>>
>>> David Holmes
>>>
>>> Pavel Tisnovsky said the following on 05/06/11 02:05:
>>>> Pavel Tisnovsky wrote:
>>>>> David Holmes wrote:
>>>>>> Dr Andrew John Hughes said the following on 11/17/10 08:55:
>>>>>>> On 16 November 2010 11:28, Pavel Tisnovsky <ptisnovs at redhat.com>
>>>>>>> wrote:
>>>>>>>> David Holmes wrote:
>>>>>>>>> This is a fix for 64-bit systems but the invoke program is still
>>>>>>>>> being
>>>>>>>>> compiled as 32-bit. I'm a little surprised it can then load the
>>>>>>>>> 64-bit VM.
>>>>>>>> it seems that "invoke" is compiled as 64-bit executable (on RHEL 5
>>>>>>>> x86_64 at least):
>>>>>>>>
>>>>>>>> invoke: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
>>>>>>>> for
>>>>>>>> GNU/Linux 2.6.9, dynamically linked (uses shared libs), for
>>>>>>>> GNU/Linux
>>>>>>>> 2.6.9, not stripped
>>>>>>> I think David may be referring to the need for -m32 or -m64,
>>>>>>> where gcc
>>>>>>> is configured. On GNU/Linux platforms, gcc tends to produce a
>>>>>>> 64-bit
>>>>>>> binary on x86_64 by default but on Solaris, it produces a 32-bit
>>>>>>> binary.
>>>>>> Exactly so - sorry didn't see your reply before my last reply.
>>>>>>
>>>>>> So in its new form the test will work correctly if run on a 64-bit
>>>>>> VM on
>>>>>> 64-bit Linux, or a 32-bit VM on 32-bit Linux, but not on a 32-bit
>>>>>> VM on
>>>>>> 64-bit Linux. (I[m not sure our internal testing ever tries the
>>>>>> latter).
>>>>>>
>>>>>> It also relies on the fact that the Linux JRE/JDK doesn't contain
>>>>>> both
>>>>>> the 64-bit and 32-bit VMs.
>>>>> Hi David,
>>>>>
>>>>> you are right, we can't assume that find select the right
>>>>> libjvm.so. I'm
>>>>> going to fix this test by other way.
>>>>>
>>>>> Thanks
>>>>> Pavel
>>>>>
>>>>>> David
>>>> Hi David,
>>>>
>>>> here is new version of fix of regression test Test6929067:
>>>> http://cr.openjdk.java.net/~ptisnovs/jtreg-runtime-test-6929067-fix/
>>>>
>>>> Can you please review it?
>>>>
>>>> Thank you in advance,
>>>> Pavel Tisnovsky
>>
More information about the hotspot-runtime-dev
mailing list