harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tianwei <tianwei.sh...@gmail.com>
Subject Re: The progress of MIPS patch work
Date Tue, 29 Dec 2009 13:13:10 GMT
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 <tianwei.sheng@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 <tianwei.sheng@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 <tianwei.sheng@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 <tianwei.sheng@gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On Thu, Dec 3, 2009 at 9:01 AM, Nathan Beyer <ndbeyer@apache.org>wrote:
>>>>
>>>>> On Wed, Dec 2, 2009 at 7:51 AM, Tianwei <tianwei.sheng@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message