Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so
Chris Plummer
chris.plummer at oracle.com
Mon Mar 6 21:54:59 UTC 2017
I haven't been following this too closely, but one thing to consider is
that you are not getting proper floating point calling conventions. You
mentioned your configure target ABI is arm-vfp-sflt. This means you have
VFP support, but use the old softfloat calling conventions (FP values
passed in GPRs). Most platforms these days with VFP support use the new
hardfloat calling conventions (FP values passed in FPRs). So this could
simply be the case of building the wrong binary for your platform.
- Use arm-vfp-hflt is you have VFP support and want to use hard float
calling
conventions.
- Use arm-vfp-sflt if you have VFP support and want to use the older
soft float
calling conventions.
- Use arm-sflt is you have a true soft float platform.
There's also a very old arm sflt ABI that I don't think we support. The
main difference from arm-sflt is the word endianess of of 64-bit values.
I believe the presence of -mfpu=vfp is what is used to get the more
modern endianess, which to say the least is very non-obvious option for
doing this, but is the reason you will see -mfpu=vfp for all our
supported arm platforms (arm-vfp-hflt, arm-vfp-sflt, and arm-sflt).
Here's the logic from the configure script:
if test "x$ARM_FLOAT_TYPE" = xvfp-sflt; then
ARM_FLOAT_TYPE_FLAGS='-mfloat-abi=softfp -mfpu=vfp
-DFLOAT_ARCH=-vfp-sflt'
elif test "x$ARM_FLOAT_TYPE" = xvfp-hflt; then
ARM_FLOAT_TYPE_FLAGS='-mfloat-abi=hard -mfpu=vfp
-DFLOAT_ARCH=-vfp-hflt'
elif test "x$ARM_FLOAT_TYPE" = xsflt; then
ARM_FLOAT_TYPE_FLAGS='-msoft-float -mfpu=vfp'
fi
BTW, for the arm-sflt case, FLOAT_ARCH gets set internally to "-sflt".
I'm not sure why for arm-sflt it's handled in the source and the other
two platforms set it in the configure script.
cheers,
Chris
On 3/5/17 8:30 PM, Zhu Yong wrote:
> Sometime later this week, I might get newer version of Marvell toolchain, I
> will do a build and test again then.
> I will update this thread when I get result.
>
> Thank you very much for helping.
>
> On Mon, Mar 6, 2017 at 9:09 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 3/03/2017 6:59 PM, Zhu Yong wrote:
>>
>>> Thank you very much for helping.
>>>
>>> Today I tried to debug the test code, but without luck, still can't
>>> figure out why.
>>>
>>> First, I followed the instruction
>>> http://stackoverflow.com/questions/29916995/intellij-idea-
>>> remotely-debug-java-console-program,
>>> changed suspend=y because the test code is short, it will exit before
>>> debug start if not suspend first. Unfortunately, with remote debug, I
>>> was not able to reproduce the issue. Same class file, directly run, will
>>> produce the issue, remote debug won't.
>>>
>>> Then, I tried *jdb *from my OpenJDK9 client vm, run directly on my
>>> target system to debug the code. If I set breakpoint, program run
>>> without issue, however, if don't set breakpoint, just "run" in jdb,
>>> problem reproduced.
>>>
>> This suggests to me that a floating-point register is not being preserved
>> when needed. When you run with the breakpoint you will get full
>> save/restore of all the register state. Just a theory.
>>
>> Next, I tried to use *javap *to decompile the output class file, run
>>> OpenJDK9 client vm javap and host side javap on same class file, the
>>> output is same for getTime function.
>>>
>> It is a native code issue not a bytecode issue, so javap wont help here.
>>
>> One interesting point I noticed today is the output like below when
>>> problem happen, 2nd call of getTime() has value of 1st call result /
>>> 1000. Looks like 2nd call getTime(), double variable q was not updated
>>> startTime: 284092.063000 endTime: 284.092063 runTime: -283807.970937
>>>
>>> What should I do so that I can come a conclusion that it's due to
>>> compiler issue?
>>>
>> Can you get access to a different gcc to build with?
>>
>> David
>> -----
>>
>>
>>> On Thu, Mar 2, 2017 at 12:32 PM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> I built your sample program with latest JDK 9 for arm-vfp-sflt and
>>> ran on an emulator I have available, and I had no issues.
>>>
>>> So I still have concerns this may be a build/compiler issue.
>>>
>>> David
>>>
>>>
>>> On 2/03/2017 12:51 PM, David Holmes wrote:
>>>
>>> I've moved this discussion over to hotspot-dev as this seems no
>>> longer a
>>> build issue but a C1 soft-float issue.
>>>
>>> David
>>>
>>> On 2/03/2017 12:35 PM, Zhu Yong wrote:
>>>
>>> If run with -Xint, it works.
>>>
>>> I have created simplified FP test by remove all non-related
>>> code from
>>> Whetstone test code.
>>> The test code is here:
>>> https://gist.github.com/yongzhy/d65c26d39fe5d549d1b406c7c84e
>>> acd4
>>> <https://gist.github.com/yongzhy/d65c26d39fe5d549d1b406c7c84
>>> eacd4>
>>>
>>> I am not sure if the test code can help or not. The
>>> behaviour is weird :
>>> - If I print both itime and q, program will run OK
>>> - inside condition block if(q<1.0f), if I use exit code
>>> 2,3,4,5, problem
>>> appears, however, if I use exit code >=6, program run OK.
>>>
>>> I always get exit code 5, the line q = (double)itime is wrong?
>>>
>>> public static double getTime()
>>> {
>>> double q;
>>> long itime;
>>> itime = System.currentTimeMillis();
>>> if(itime<1000000) {
>>> System.exit(1);
>>> }
>>> //System.out.printf("time long value %d\n",
>>> itime);
>>> q = (double) itime;
>>> if(q < 1.0f) {
>>> System.exit(5); // I always get exit code 5
>>> }
>>> //System.out.printf("time float value %f\n", q);
>>> return q / 1000.0;
>>> }
>>>
>>>
>>>
>>> On Wed, Mar 1, 2017 at 5:31 PM, David Holmes
>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>> wrote:
>>>
>>> On 1/03/2017 6:45 PM, Zhu Yong wrote:
>>>
>>> OK, for the Whetstone Benchmark, I added debug
>>> printing and
>>> found it's
>>> due to function getTime(), it only get good value on
>>> 1st call,
>>> all
>>> following calls get 0s.
>>> Debug printing of itime value is correct. So reason
>>> should be
>>> the return
>>> division line. Could it because toolchain's floating
>>> point
>>> operation???
>>> But why server VM Ok?
>>>
>>>
>>> Server and client implement FP logic differently, and
>>> particularly
>>> as this is soft-fp, they may well not be in sync. Does
>>> -Xint work?
>>>
>>> Can you isolate to a simple FP test?
>>>
>>> David
>>>
>>> public static double getTime()
>>> {
>>> double q;
>>> long itime;
>>> itime = System.currentTimeMillis();
>>> q = (double) itime;
>>> return q / 1000.0;
>>> }
>>>
>>> On Wed, Mar 1, 2017 at 3:14 PM, David Holmes
>>> <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>> wrote:
>>>
>>> On 1/03/2017 4:26 PM, Zhu Yong wrote:
>>>
>>> We use armv7-marvell-linux-gnueabi-softfp
>>> toolchain
>>>
>>> gcc version 4.6.4 (Marvell GCC release
>>> 20150204-c4af733b 64K
>>> MAXPAGESIZE
>>> ALIGN CVE-2015-0235)
>>>
>>> Is this toolchain too old? I am asking
>>> because I saw
>>> other strange
>>> issues as well:
>>>
>>>
>>> We last used gcc 4.7.2. I can't really say if
>>> 4.6.4 is "too
>>> old".
>>>
>>> I have successfully build server, client and
>>> minimal VM,
>>> when I run
>>> Dhrystone benchmark file (the same jar file
>>> from
>>> http://www.okayan.jp/DhrystoneApplet/
>>> <http://www.okayan.jp/DhrystoneApplet/>
>>> <http://www.okayan.jp/DhrystoneApplet/
>>> <http://www.okayan.jp/DhrystoneApplet/>>
>>> <http://www.okayan.jp/DhrystoneApplet/
>>> <http://www.okayan.jp/DhrystoneApplet/>
>>> <http://www.okayan.jp/DhrystoneApplet/
>>> <http://www.okayan.jp/DhrystoneApplet/>>>), the performance
>>> from
>>> server VM
>>> is much better than client and minimal VM.
>>> (minimal: 1629852, client: 1615508, server:
>>> 2338871 )
>>>
>>>
>>> That's expected. The server VM is high
>>> performance.
>>>
>>> And when run Whetstone Benchmark
>>> from
>>>
>>> http://www.roylongbottom.org.uk/online/whetjava2.html
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html>
>>>
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html>>
>>>
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html>
>>>
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html
>>> <http://www.roylongbottom.org.uk/online/whetjava2.html>>>,
>>> server VM
>>> finished with good result, client and
>>> minimal VM not
>>> able to finish
>>> (program stuck there forever after print 1st
>>> line of
>>> output).
>>>
>>>
>>> That needs investigating. You need to try and
>>> generate a
>>> stackdump
>>> to see where things are stuck.
>>>
>>> David
>>>
>>>
>>> On Wed, Mar 1, 2017 at 1:56 PM, David Holmes
>>> <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com <mailto:
>>> david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>>> wrote:
>>>
>>> On 1/03/2017 3:39 PM, Zhu Yong wrote:
>>>
>>> Thank you for the information, I
>>> managed to make
>>> minimal
>>> build
>>> pass now.
>>>
>>> Initially I though JVM_EXCLUDE_FILES
>>> need to add
>>> additional 3
>>> generated
>>> files (they appeared
>>> in _BUILD_LIBJVM_objectfilenames.txt)
>>> :
>>> bytecodeInterpreterWithChecks.cpp
>>> jvmtiEnter.cpp
>>> jvmtiEnterTrace.cpp
>>> But build still fail with same error
>>> message.
>>>
>>> Finally I figured out it's due to
>>> those 8 doit()
>>> functions
>>> implementation in jvmtiEnvBase.hpp
>>> file. After
>>> move all
>>> those 8
>>> doit()
>>> implementations to jvmtiEnvBase.cpp,
>>> build of
>>> minimal VM
>>> passed
>>> without
>>> any issue.
>>>
>>>
>>> That seems to be a compiler issue.
>>> jvmtiEnvBase.hpp is
>>> unconditionally included in a couple of
>>> places
>>> because we
>>> have to
>>> have enough of the JVMTI code to say
>>> JVMTI is not
>>> available.
>>> Those
>>> doit() implementations, though arguably
>>> could be
>>> conditional on
>>> INCLUDE_JVMTI, are not referenced by any
>>> called code
>>> and so
>>> should
>>> not linked in. But in your case it seems
>>> they are.
>>>
>>> What toolchain are you using?
>>>
>>> David
>>> -----
>>>
>>> Changes appended
>>> =============
>>>
>>> ---
>>> .../src/share/vm/prims/jvmtiE
>>> nvBase.cpp
>>> | 74
>>> ++++++++++++++++++++++
>>> .../src/share/vm/prims/jvmtiE
>>> nvBase.hpp
>>> | 68
>>> +++-----------------
>>> 2 files changed, 82 insertions(+), 60
>>> deletions(-)
>>> mode change 100644 => 100755
>>>
>>> hotspot-9211c2e89c1c/src/share
>>> /vm/prims/jvmtiEnvBase.cpp
>>> mode change 100644 => 100755
>>>
>>> hotspot-9211c2e89c1c/src/share
>>> /vm/prims/jvmtiEnvBase.hpp
>>>
>>> diff --git
>>>
>>>
>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.cpp
>>>
>>>
>>> b/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.cpp
>>> old mode 100644
>>> new mode 100755
>>> index dd241a0..e5832ba
>>> ---
>>>
>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.cpp
>>> +++
>>>
>>> b/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.cpp
>>> @@ -1283,6 +1283,80 @@
>>>
>>> VM_GetMultipleStackTraces::all
>>> ocate_and_fill_stacks(jint
>>> thread_count) {
>>> "the last copied frame
>>> info must be
>>> the last
>>> record");
>>> }
>>>
>>> +void
>>> +VM_UpdateForPopTopFrame::doit() {
>>> + JavaThread* jt =
>>> _state->get_thread();
>>> + if (Threads::includes(jt) &&
>>> !jt->is_exiting() &&
>>> jt->threadObj() !=
>>> NULL) {
>>> + _state->update_for_pop_top_fra
>>> me();
>>> + } else {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + }
>>> +}
>>> +
>>> +void
>>> +VM_SetFramePop::doit() {
>>> + JavaThread* jt =
>>> _state->get_thread();
>>> + if (Threads::includes(jt) &&
>>> !jt->is_exiting() &&
>>> jt->threadObj() !=
>>> NULL) {
>>> + int frame_number =
>>> _state->count_frames() -
>>> _depth;
>>> +
>>>
>>>
>>>
>>> _state->env_thread_state((JvmtiEnvBase*)_env)->set_frame_
>>> pop(frame_number);
>>>
>>> + } else {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + }
>>> +}
>>> +
>>> +void
>>> +VM_GetOwnedMonitorInfo::doit() {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting()
>>> +
>>> &&
>>> _java_thread->threadObj() !=
>>> NULL) {
>>> + _result = ((JvmtiEnvBase
>>>
>>> *)_env)->get_owned_monitors(_calling_thread,
>>> _java_thread,
>>> +
>>> _owned_monitors_list);
>>> + }
>>> +}
>>> +
>>> +void
>>> +VM_GetObjectMonitorUsage::doit() {
>>> + _result = ((JvmtiEnvBase*)
>>>
>>> _env)->get_object_monitor_usage(_calling_thread,
>>> _object,
>>> _info_ptr);
>>> +}
>>> +
>>> +void
>>> +VM_GetCurrentContendedMonitor::doit()
>>> {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting() &&
>>> + _java_thread->threadObj() !=
>>> NULL) {
>>> + _result = ((JvmtiEnvBase
>>>
>>>
>>>
>>> *)_env)->get_current_contended_monitor(_calling_thread,_
>>> java_thread,_owned_monitor_ptr);
>>>
>>> + }
>>> +}
>>> +
>>> +void
>>> +VM_GetStackTrace::doit() {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting()
>>> +
>>> &&
>>> _java_thread->threadObj() !=
>>> NULL) {
>>> + _result = ((JvmtiEnvBase
>>> *)_env)->get_stack_trace(_java_thread,
>>> +
>>> _start_depth,
>>> _max_count,
>>> +
>>> _frame_buffer,
>>> _count_ptr);
>>> + }
>>> +}
>>> +
>>> +void
>>> +VM_GetFrameCount::doit() {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + JavaThread* jt =
>>> _state->get_thread();
>>> + if (Threads::includes(jt) &&
>>> !jt->is_exiting() &&
>>> jt->threadObj() !=
>>> NULL) {
>>> + _result =
>>> ((JvmtiEnvBase*)_env)->get_fra
>>> me_count(_state,
>>> _count_ptr);
>>> + }
>>> +}
>>> +
>>> +void
>>> +VM_GetFrameLocation::doit() {
>>> + _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> + if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting() &&
>>> + _java_thread->threadObj() !=
>>> NULL) {
>>> + _result =
>>>
>>> ((JvmtiEnvBase*)_env)->get_fra
>>> me_location(_java_thread,
>>> _depth,
>>> +
>>> _method_ptr,
>>> _location_ptr);
>>> + }
>>> +}
>>>
>>> void
>>> VM_GetThreadListStackTraces::doit()
>>> {
>>> diff --git
>>>
>>>
>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>>
>>>
>>> b/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>> old mode 100644
>>> new mode 100755
>>> index 04e6869..00b9890
>>> ---
>>>
>>> a/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>> +++
>>>
>>> b/hotspot-9211c2e89c1c/src/share/vm/prims/jvmtiEnvBase.hpp
>>> @@ -359,14 +359,7 @@ public:
>>> }
>>> VMOp_Type type() const { return
>>> VMOp_UpdateForPopTopFrame; }
>>> jvmtiError result() { return
>>> _result; }
>>> - void doit() {
>>> - JavaThread* jt =
>>> _state->get_thread();
>>> - if (Threads::includes(jt) &&
>>> !jt->is_exiting() &&
>>> jt->threadObj()
>>> != NULL) {
>>> -
>>> _state->update_for_pop_top_frame();
>>> - } else {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - }
>>> - }
>>> + void doit();
>>> };
>>>
>>> // VM operation to set frame pop.
>>> @@ -389,15 +382,7 @@ public:
>>> bool allow_nested_vm_operations()
>>> const {
>>> return true; }
>>> VMOp_Type type() const { return
>>> VMOp_SetFramePop; }
>>> jvmtiError result() { return
>>> _result; }
>>> - void doit() {
>>> - JavaThread* jt =
>>> _state->get_thread();
>>> - if (Threads::includes(jt) &&
>>> !jt->is_exiting() &&
>>> jt->threadObj()
>>> != NULL) {
>>> - int frame_number =
>>> _state->count_frames()
>>> - _depth;
>>> -
>>>
>>>
>>>
>>> _state->env_thread_state((JvmtiEnvBase*)_env)->set_frame_
>>> pop(frame_number);
>>>
>>> - } else {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - }
>>> - }
>>> + void doit();
>>> };
>>>
>>>
>>> @@ -421,14 +406,7 @@ public:
>>> _result = JVMTI_ERROR_NONE;
>>> }
>>> VMOp_Type type() const { return
>>> VMOp_GetOwnedMonitorInfo; }
>>> - void doit() {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting()
>>> -
>>> &&
>>> _java_thread->threadObj() !=
>>> NULL) {
>>> - _result = ((JvmtiEnvBase
>>>
>>> *)_env)->get_owned_monitors(_calling_thread,
>>> _java_thread,
>>> -
>>> _owned_monitors_list);
>>> - }
>>> - }
>>> + void doit();
>>> jvmtiError result() { return
>>> _result; }
>>> };
>>>
>>> @@ -451,10 +429,7 @@ public:
>>> }
>>> VMOp_Type type() const { return
>>> VMOp_GetObjectMonitorUsage; }
>>> jvmtiError result() { return
>>> _result; }
>>> - void doit() {
>>> - _result = ((JvmtiEnvBase*)
>>>
>>> _env)->get_object_monitor_usage(_calling_thread,
>>> _object,
>>> _info_ptr);
>>> - }
>>> -
>>> + void doit();
>>> };
>>>
>>> // VM operation to get current
>>> contended
>>> monitor.
>>> @@ -475,13 +450,7 @@ public:
>>> }
>>> VMOp_Type type() const { return
>>> VMOp_GetCurrentContendedMonitor; }
>>> jvmtiError result() { return
>>> _result; }
>>> - void doit() {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting() &&
>>> - _java_thread->threadObj()
>>> != NULL) {
>>> - _result = ((JvmtiEnvBase
>>>
>>>
>>>
>>> *)_env)->get_current_contended_monitor(_calling_thread,_
>>> java_thread,_owned_monitor_ptr);
>>>
>>> - }
>>> - }
>>> + void doit();
>>> };
>>>
>>> // VM operation to get stack trace
>>> at safepoint.
>>> @@ -508,15 +477,7 @@ public:
>>> }
>>> jvmtiError result() { return
>>> _result; }
>>> VMOp_Type type() const { return
>>> VMOp_GetStackTrace; }
>>> - void doit() {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting()
>>> -
>>> &&
>>> _java_thread->threadObj() !=
>>> NULL) {
>>> - _result = ((JvmtiEnvBase
>>> *)_env)->get_stack_trace(_java
>>> _thread,
>>> -
>>> _start_depth,
>>> _max_count,
>>> -
>>> _frame_buffer,
>>> _count_ptr);
>>> - }
>>> - }
>>> + void doit();
>>> };
>>>
>>> // forward declaration
>>> @@ -606,13 +567,7 @@ public:
>>> }
>>> VMOp_Type type() const { return
>>> VMOp_GetFrameCount; }
>>> jvmtiError result() { return
>>> _result; }
>>> - void doit() {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - JavaThread* jt =
>>> _state->get_thread();
>>> - if (Threads::includes(jt) &&
>>> !jt->is_exiting() &&
>>> jt->threadObj()
>>> != NULL) {
>>> - _result =
>>> ((JvmtiEnvBase*)_env)->get_fra
>>> me_count(_state,
>>> _count_ptr);
>>> - }
>>> - }
>>> + void doit();
>>> };
>>>
>>> // VM operation to frame location
>>> at safepoint.
>>> @@ -636,14 +591,7 @@ public:
>>> }
>>> VMOp_Type type() const { return
>>> VMOp_GetFrameLocation; }
>>> jvmtiError result() { return
>>> _result; }
>>> - void doit() {
>>> - _result =
>>> JVMTI_ERROR_THREAD_NOT_ALIVE;
>>> - if
>>> (Threads::includes(_java_thread) &&
>>> !_java_thread->is_exiting() &&
>>> - _java_thread->threadObj()
>>> != NULL) {
>>> - _result =
>>>
>>> ((JvmtiEnvBase*)_env)->get_fra
>>> me_location(_java_thread,
>>> _depth,
>>> -
>>> _method_ptr,
>>> _location_ptr);
>>> - }
>>> - }
>>> + void doit();
>>> };
>>>
>>>
>>> --
>>> 2.1.4
>>>
>>>
>>> On Tue, Feb 28, 2017 at 6:11 PM,
>>> David Holmes
>>> <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>
>>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>
>>> <mailto:david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>>>>>> wrote:
>>>
>>> On 28/02/2017 7:35 PM, David
>>> Holmes wrote:
>>>
>>> On 28/02/2017 6:51 PM, Zhu
>>> Yong wrote:
>>>
>>> Dear All,
>>>
>>> I am testing cross compile
>>> OpenJDK-9+158 for our
>>> embedded
>>> system using
>>> buildroot, I can build
>>> server and
>>> client
>>> variants
>>> successfully, but the
>>> output compact1 profile
>>> file size
>>> is too
>>> big, then I
>>> tried
>>> to build
>>> minimal
>>> variant, failed when
>>> linking
>>> libjvm.so.
>>>
>>> I checked
>>>
>>>
>>>
>>>
>>> build/linux-arm-normal-minimal-release/hotspot/variant-
>>> minimal/
>>>
>>> libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt,
>>> jvmtiEnvBase.o
>>> and
>>> jvmtiEnvThreadState.o are not
>>> listed in
>>> the file
>>> (which
>>> is required
>>> from the error message
>>> below).
>>>
>>>
>>> Right - JVM TI is not part
>>> of the
>>> Minimal VM. At the
>>> moment it looks
>>> like some service has either
>>> been
>>> enabled when
>>> it should not
>>> have been,
>>> or has not been correctly
>>> if'def in the
>>> source.
>>>
>>>
>>> As far as I can see your error
>>> messages are
>>> complaining about
>>> missing functions that are
>>> called from the
>>> same
>>> sources as the
>>> functions that are missing! ie.
>>>
>>> undefined reference to
>>>
>>>
>>> `JvmtiEnvBase::get_current_contended_monitor(JavaThread*,
>>> JavaThread*,
>>> _jobject**)'
>>> /tmp/cc27HS5M.ltrans0.ltrans.o:
>>> In function
>>> `VM_GetOwnedMonitorInfo::doit()
>>>
>>> but VM_GetOwnedMonitorInfo is
>>> defined in
>>> jvmtiEnv.cpp which
>>> should
>>> be included or excluded the same
>>> as
>>> jvmtiEnBase.cpp.
>>> Here's the
>>> logic in the makefile that
>>> controls this:
>>>
>>> ifneq ($(call check-jvm-feature,
>>> jvmti),
>>> true)
>>> JVM_CFLAGS_FEATURES +=
>>> -DINCLUDE_JVMTI=0
>>> JVM_EXCLUDE_FILES +=
>>> jvmtiGetLoadedClasses.cpp
>>> jvmtiThreadState.cpp
>>> jvmtiExtensions.cpp \
>>> jvmtiImpl.cpp
>>> jvmtiManageCapabilities.cpp
>>> jvmtiRawMonitor.cpp
>>> jvmtiUtil.cpp jvmtiTrace.cpp \
>>> jvmtiCodeBlobEvents.cpp
>>> jvmtiEnv.cpp
>>> jvmtiRedefineClasses.cpp
>>> jvmtiEnvBase.cpp
>>> jvmtiEnvThreadState.cpp \
>>> jvmtiTagMap.cpp
>>> jvmtiEventController.cpp
>>> evmCompat.cpp
>>> jvmtiEnter.xsl jvmtiExport.cpp \
>>>
>>> jvmtiClassFileReconstituter.cpp
>>> endif
>>>
>>> Can you run with LOG=trace so
>>> that each
>>> compiled file is
>>> listed in
>>> the build log, then see if there
>>> are any
>>> jvmti*
>>> files listed
>>> there.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>
>>>
>>> Can you provide the lines
>>> from your
>>> spec.gmk
>>> that define the
>>> JVM_FEATURES_* variables
>>> please.
>>>
>>> Thanks,
>>> David
>>> ------
>>>
>>>
>>> === Output from failing
>>> command(s)
>>> repeated
>>> here ===
>>> * For target
>>>
>>>
>>> hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link:
>>>
>>> /tmp/cc27HS5M.ltrans0.ltrans.o: In
>>> function
>>> `VM_GetStackTrace::doit()
>>> [clone .local.640]':
>>
More information about the hotspot-dev
mailing list