You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tianwei <ti...@gmail.com> on 2010/01/02 16:20:19 UTC
Re: The progress of MIPS patch work
Hi, Charles,
I finally made a milestone, and get the interpreter works for
"HelloWorld", the following is the result:
stw@RAYS-b0f748fa:~/test$
/home/stw/harmony/harmony-nofetch/working_vm/build/linux_mips32_gcc_debug/deploy/jdk/jre/bin/java
-Xint HelloWorldApp
Hello World!
Please ignore the previous mail, I made a mistake to comment out the
following line in
interp_native_mips.cpp:
case JAVA_TYPE_DOUBLE:
case JAVA_TYPE_LONG:
/* MIPS ABI requires 64 bit values to be
naturally aligned.
* pad here and increase array size if required.
*/
if ((argId & 1) != 0) {
sz++;
arg_words2 = (uword*)ALLOC_FRAME((sz + 2)
* sizeof(uword));
if (!arg_words2) {
DIE(("no memory for frame"));
}
memcpy(arg_words2, arg_words, argId *
sizeof(uword));
FREE_FRAME(arg_words);
arg_words = arg_words2;
argId++;
}
Value2 val;
val.i64 = args[pos++].j;
arg_words[argId++] = val.v[0].i;
arg_words[argId++] = val.v[1].i;
break;
I comment out the padding code, this will give me the following error, for
example:
JNIEXPORT void JNICALL
Java_java_util_zip_Inflater_setInputImpl (JNIEnv * env, jobject recv,
jbyteArray buf, jint off, jint
len,
jlong handle)
{
............
}
it has 6 arguments, in the interpreter, before call this JNI, if comment out
the padding code, the args is:
(gdb) p args[4]
$88 = 512
(gdb) p args[5]
$85 = 10515904
(gdb) p args[6]
$86 = 0
args[5] and args[6] are for jlong, but the MIPS ABI need to align, so we
need to modify it as:
args[4] =512, args[5]=0
args[6] = 10515904, args[7]=0
when I enable the padding code, it works.
Other issues are mainly about get and set value for JAVA_TYPE_LONG, I
believe the original patch has some problems, my fix looks like:
Value2 val;
val.i64 = args[pos++].j;
arg_words[argId++] = val.v[0].i;
arg_words[argId++] = val.v[1].i;
break;
summary:
(1) the interpreter works for "HelloWorld" based on Charles's patch on my
MIPS machines.
(2) I only knew very little about the harmony and JVM, only use gdb and
trace to solve the problem, I will continue to
learn them.
(3) next step, I will continue to test more cases and polish my code.
BTW, Is there any updates for merging your patch into upstream? Since now
I make the interpreter work, I also can help testing.
Thanks.
Tianwei
On Tue, Dec 29, 2009 at 9:13 PM, Tianwei <ti...@gmail.com> wrote:
> 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 <ti...@gmail.com> 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 <ti...@gmail.com> 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 <ti...@gmail.com>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:
>>>> stw@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 <ti...@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 3, 2009 at 9:01 AM, Nathan Beyer <nd...@apache.org>wrote:
>>>>>
>>>>>> On Wed, Dec 2, 2009 at 7:51 AM, Tianwei <ti...@gmail.com>
>>>>>> 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.
>
--
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.