Well, after two day's debugging, the root cause is that there is some
problem with the parameter passing in original patch on my machine, some of
the code looks like:
--- interpreter.cpp (revision 162)
+++ interpreter.cpp (working copy)
@@ -1691,10 +1691,10 @@
case VM_DATA_TYPE_INT64:
case VM_DATA_TYPE_F8:
{
- double *vaddr = (double*) addr;
- *vaddr = frame.stack.getLong(0).d;
- frame.stack.pop(2);
- break;
+ //double *vaddr = (double*) addr;
+ *(I_64*)addr = frame.stack.getLong(0).i64;
+ frame.stack.pop(2);
+ break;
}
===================================================================
--- interp_native_mips.cpp (revision 162)
+++ interp_native_mips.cpp (working copy)
case JAVA_TYPE_DOUBLE:
case JAVA_TYPE_LONG:
- args[argId+0] = prevFrame.stack.pick(pos-0).u;
- args[argId+1] = prevFrame.stack.pick(pos-1).u;
- argId += 2;
- pos -= 2;
- break;
+ Value2 val;
+ val.i64 = prevFrame.stack.getLong(pos-1).i64;
+ args[argId+0] = val.v[0].i;
+ args[argId+1] = val.v[1].i;
+ argId += 2;
+ pos -= 2;
+ break;
I guess the fix is not fully right(does not handle double), but at least the
orignal patch do not have a consistent usage for "JAVA_TYPE_LONG".
Tianwei
On Sun, Dec 27, 2009 at 8:40 PM, Tianwei <[email protected]> wrote:
> sorry, miss something for the previous trace:
> [trace] StartLoading class [Ljava/lang/StackTraceElement; with loader
> 0x450fc0
> [trace] initializing class java/lang/System
> [trace] initializing class java/lang/System STEP 2
> [trace] StartLoading class java/lang/NoClassDefFoundError with loader
> 0x450fc0
> [trace] initializing class java/lang/NoClassDefFoundError
> [trace] initializing class java/lang/NoClassDefFoundError STEP 2
> [trace] initializing class java/lang/NoClassDefFoundErrorSTEP 6
> [trace] class java/lang/NoClassDefFoundError initialized
> [trace] exn_raise_object(), propagating lazy & non-destructively
> [trace] interpreter: 0x6f3608.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x6f3440.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x6f31b0.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x6f2ec8.<init>(Ljava/lang/String;)V
> [trace] interpreter: 0x468358.<init>()V
> [trace] interpreter: 0x6f2ec8.fillInStackTrace()Ljava/lang/Throwable;
> [trace] interpreter static native:
> 0x787048.getStackState()Ljava/lang/Object;
> [trace] interpreter static native:
> 0x787048.getStackClasses(Ljava/lang/Object;)[Ljava/lang/Class;
>
>
> Does that mean it has some problem with loading
> "[Ljava/lang/StackTraceElement"?
>
> Thanks.
>
> Tianwei
> On Sun, Dec 27, 2009 at 8:26 PM, Tianwei <[email protected]> wrote:
>
>> OK, when using -Xtrace:harmonyvm, the tail of the trace looks like:
>> trace] interpreter: 0x6f2740.toString()Ljava/lang/String;
>> [trace] interpreter: 0x6f2740.toString()Ljava/lang/String;
>> [trace] interpreter: 0x6f3498.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x6f32d0.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x6f3040.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x6f2d58.<init>(Ljava/lang/String;)V
>> [trace] interpreter: 0x4682f8.<init>()V
>> [trace] interpreter: 0x6f2d58.fillInStackTrace()Ljava/lang/Throwable;
>> [trace] interpreter static native:
>> 0x786ed8.getStackState()Ljava/lang/Object;
>> [trace] interpreter static native:
>> 0x786ed8.getStackClasses(Ljava/lang/Object;)[Ljava/lang/Class;
>> java:
>> /home/stw/harmony/harmony-nofetch/working_vm/vm/vmcore/src/exception/exceptions.cpp:574:
>> exn_native_print_stack_trace: Assertion `hythread_is_suspend_enabled()'
>> failed.
>> Aborted
>>
>> Tianwei
>>
>> On Sun, Dec 27, 2009 at 7:59 PM, Tianwei <[email protected]> wrote:
>>
>>> Hi, all,
>>> I met a difficult problem again. Now based on Charles's patch, I can
>>> go further on my MIPS machine. But I met the following error when using
>>> interpreter:
>>> s...@rays-b0f748fa:~/test$
>>> /home/stw/harmony/harmony-nofetch/working_vm/build/linux_mips32_gcc_debug/deploy/jdk/jre/bin/java
>>> -Xint -Xtrace:vm.core HelloWorldApp
>>>
>>> checking table sizes: 96/96
>>>
>>> checking table sizes: 96/96
>>>
>>> [trace] Initializing VM
>>>
>>> [trace] analyzing em dll libem.so
>>>
>>> [trace] analyzing gc.dll libgc_gen_uncomp.so
>>>
>>> [trace] bootstrapping initial java classes
>>>
>>> [trace] bootstrapping initial java classes complete
>>>
>>> [trace] get class methods : java/lang/Thread
>>>
>>> [trace] Failed to initialize new thread object, exception =
>>> java/lang/ExceptionInInitializerError
>>>
>>> java/lang/ExceptionInInitializerError : (null)
>>> java:
>>> /home/stw/harmony/harmony-nofetch/working_vm/vm/vmcore/src/exception/exceptions.cpp:574:
>>> exn_native_print_stack_trace: Assertion `hythread_is_suspend_enabled()'
>>> failed.
>>> Aborted
>>>
>>>
>>> I debug the code with gdb a lot(compared with X86_64 version), but was
>>> lost inside the large code base. I also were reading Harmony's document and
>>> try to understand the whole framework. But it's really very difficult ;-(
>>> I want to know if someone can give me some suggestions for such bugs,
>>> also are there any useful debugging tips(trace, logging facilities) for my
>>> porting work?
>>>
>>> more information for the exception, I use gdb to trace the bug for the
>>> source code is:
>>> void
>>> interpreter(StackFrame &frame) {
>>> while (true) {
>>> ip0 = *frame.ip;
>>> switch(ip0) {
>>> ...............
>>> case OPCODE_INVOKESTATIC:
>>> Opcode_INVOKESTATIC(frame);
>>> frame.exc =
>>> get_current_thread_exception();
>>> if (frame.exc != 0) goto got_exception;
>>> frame.ip += 3;
>>> break;
>>>
>>> }
>>> got_exception:
>>> ................
>>> }
>>>
>>> but hard to further locate the root cause.
>>>
>>> Any suggestions?
>>>
>>> Thanks very much
>>>
>>> Tianwei
>>> On Thu, Dec 3, 2009 at 10:31 AM, Tianwei <[email protected]>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Dec 3, 2009 at 9:01 AM, Nathan Beyer <[email protected]>wrote:
>>>>
>>>>> On Wed, Dec 2, 2009 at 7:51 AM, Tianwei <[email protected]>
>>>>> wrote:
>>>>> > Hi, all,
>>>>> > I got some progress for applying Charles's patch sent two weeks
>>>>> ago.
>>>>> > However, I also met some hard issues which I want to ask for
>>>>> suggestions.
>>>>> > I am totally new for harmony development, so I want to hear your
>>>>> valuable
>>>>> > suggestions for my work.
>>>>> > My experiments step are:
>>>>> > 1. apply the patch on X86_64 (ubuntu 9.04)
>>>>> > at this step, I also checkout a clean trunk, maintain two
>>>>> directories
>>>>> > trunk and trunk-mips(patched by MIPS patch)
>>>>> > after fixing some problems, I compare the testing result(ant test)
>>>>> for
>>>>> > these two versions, the result is same where I assume the modified
>>>>> patch
>>>>> > work on X86(no regression).
>>>>> > for this step, the main problems of original patch are:
>>>>> > a. there is some problem when using "unless", such as:
>>>>> > --- working_vm/make/vm/interpreter.xml (revision 833674)
>>>>> > +++ working_vm/make/vm/interpreter.xml (working copy)
>>>>> > @@ -71,6 +71,7 @@
>>>>> > <exclude name="interp_native_ia32.cpp"
>>>>> unless="is.x86"/>
>>>>> > <exclude name="interp_native_ipf.cpp"
>>>>> unless="is.ia64"/>
>>>>> > <exclude name="interp_native_em64t.cpp"
>>>>> > unless="is.x86_64"/>
>>>>> > + <exclude name="interp_native_mips.cpp"
>>>>> unless="is.mips"/>
>>>>> > </fileset>
>>>>>
>>>>> Perhaps this is obvious, but is the 'is.mips' property being setup?
>>>>> When you run 'ant echo' in the 'working_classlib' folder do you see a
>>>>> 'is.mips' line in with the other platforms, like this.
>>>>>
>>>>> [echo] is.windows = ${is.windows}
>>>>> [echo] is.unix = true
>>>>> [echo] is.linux = true
>>>>> [echo] is.freebsd = ${is.freebsd}
>>>>> [echo] is.macosx = ${is.macosx}
>>>>> [echo] is.aix = ${is.aix}
>>>>> [echo] is.zos = ${is.zos}
>>>>> [echo] is.32bit = true
>>>>> [echo] is.64bit = ${is.64bit}
>>>>> [echo] is.x86 = true
>>>>> [echo] is.x86_64 = ${is.x86_64}
>>>>> [echo] is.ia64 = ${is.ia64}
>>>>> [echo] is.ppc32 = ${is.ppc32}
>>>>> [echo] is.ppc64 = ${is.ppc64}
>>>>> [echo] is.s390 = ${is.s390}
>>>>> [echo] is.s390x = ${is.s390x}
>>>>>
>>>>>
>>>>> Ah, I did not see the is_mips32, but I added the line in
>>>> common_resources/make/platform.xml where I thought it would set is_mips32
>>>> according to $os_arch. I think this should be set because I used this to
>>>> add the defineset, such as -D_MIPS_.
>>>>
>>>> Tianwei
>>>>
>>>>> > b. the original patch has several problems under the
>>>>> > working_vm/vm/jitrino/src/jet directory, so I do not use the diff
>>>>> for that
>>>>> > directory
>>>>> >
>>>>> > 2. apply the patch on my MIPS machine
>>>>> > at this step, I mainly fix a lot of ant make system error since
>>>>> the
>>>>> > original patch did not include the makefile patch as Charles said.
>>>>> > typical fixes mainly include:
>>>>> > a. copy the linux_ppc32.mk to linux_mips32.mk
>>>>> > b. comment out the ABORT where I can not find the definition
>>>>> > c.
>>>>> > /home/stw/harmony/harmony-nofetch/common_resources/make/platform.xml
>>>>> > + <condition property="is.mips32">
>>>>> >
>>>>> > + <or>
>>>>> > + <equals arg1="${os.arch}" arg2="mips32" />
>>>>> > + <equals arg1="${os.arch}" arg2="mips" />
>>>>> > + </or>
>>>>> > + </condition>
>>>>> > + <condition property="is.mips64">
>>>>> > + <equals arg1="${os.arch}" arg2="mips64" />
>>>>> > + </condition>
>>>>> > d: manually build the icu-3.4 library since no prebuilt library
>>>>> package
>>>>> > available
>>>>> > e: vmcore.xml
>>>>> > + <include
>>>>> > name="vmcore/src/util/mips/base_natives" if="is.mips32"/>
>>>>> > + <include name="port/src/encoder/mips"
>>>>> > if="is.mips32"/>
>>>>> > + <include
>>>>> name="vmcore/src/lil/mips/include"
>>>>> > if="is.mips32"/>
>>>>> > ...................others minor fixes...........
>>>>> > 3. after step 2, I finally can build the whole hdk(working_classlib,
>>>>> > working_vm, working_jdktools), then I tried to run the
>>>>> HelloWorld.java,
>>>>> > however, I met segmentation fault at the very begging of the
>>>>> launcher.
>>>>> > I debug this problem, and the following is my finding now:
>>>>> > a. the gdb backtrace is:
>>>>> > (gdb) bt
>>>>> > #0 0x2aaf5164 in apr_initialize () at misc/unix/start.c:46
>>>>> > #1 0x2aaebecc in hythread_lib_create (lib=0x2ab299b0) at
>>>>> > /home/stw/harmony/harmony-nofetch/working_vm/vm/thread/src/thread_i\
>>>>> > nit.c:176
>>>>> > #2 0x2aaebe54 in hythread_library_init () at
>>>>> >
>>>>> /home/stw/harmony/harmony-nofetch/working_vm/vm/thread/src/thread_init.c:70
>>>>> > b. when I use disass under gdb, I found that one instruction
>>>>> > in apr_initialize caused the problem:
>>>>> > 0x2aaf5160 <apr_initialize+28>: lui v0,0x5
>>>>> > 0x2aaf5164 <apr_initialize+32>: lw v1,-9760(v0)
>>>>> > c. then I suspect its apr's problem, so I rebuilt the apr with
>>>>> -O0, then
>>>>> > first verify using the test/testall, all tests passed
>>>>> > I even execute the test/sockperf alone, it also pass, note
>>>>> that
>>>>> > sockperf call apr_initialize in its main function, but no
>>>>> segmentation
>>>>> > fault,
>>>>> > so I assume apr has no problems.
>>>>> > d. then I rebuilt the hdk, but the segmentation problem still
>>>>> exists.
>>>>> > e. finally I suspect that there may be some problem with gp
>>>>> issues, but
>>>>> > I have no clues. When checking how the launcher is built, I am
>>>>> confused with
>>>>> > libhythr.so, it seems that the launcher is first built under
>>>>> > working_classlib, link with libhythr.so under
>>>>> > working_classlib/modules/portlib/src/main/native/thread/, then after
>>>>> the
>>>>> > launcher is copied into working_vm, it will be linked with
>>>>> libhythr.so
>>>>> > under working_vm/vm/thread/src/, is that right?
>>>>> > but I still can not figure out the root cause, can anyone give
>>>>> me
>>>>> > some suggestions for this hard issue, or someone also experienced
>>>>> similar
>>>>> > issues before?
>>>>> >
>>>>> >
>>>>> > the Summary:
>>>>> > 1. no regression on X86_64 for the MIPS patch
>>>>> > 2. buildable on MIPS for that patch
>>>>> > 3. running time error(segmentation fault) at the very begging of
>>>>> the
>>>>> > launcher on MIPS
>>>>> >
>>>>> >
>>>>> > Thanks.
>>>>> >
>>>>> > Tianwei
>>>>> > --
>>>>> > Sheng, Tianwei
>>>>> > Inst. of High Performance Computing
>>>>> > Dept. of Computer Sci. & Tech.
>>>>> > Tsinghua Univ.
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sheng, Tianwei
>>>> Inst. of High Performance Computing
>>>> Dept. of Computer Sci. & Tech.
>>>> Tsinghua Univ.
>>>>
>>>
>>>
>>>
>>> --
>>> Sheng, Tianwei
>>> Inst. of High Performance Computing
>>> Dept. of Computer Sci. & Tech.
>>> Tsinghua Univ.
>>>
>>
>>
>>
>> --
>> Sheng, Tianwei
>> Inst. of High Performance Computing
>> Dept. of Computer Sci. & Tech.
>> Tsinghua Univ.
>>
>
>
>
> --
> Sheng, Tianwei
> Inst. of High Performance Computing
> Dept. of Computer Sci. & Tech.
> Tsinghua Univ.
>
--
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.
