Please review correction of regression test Test6929067

Pavel Tisnovsky ptisnovs at redhat.com
Fri May 6 02:57:04 PDT 2011


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)

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