Return-Path: 
 <dev-return-38743-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org>
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 20293 invoked from network); 27 Dec 2009 12:27:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 27 Dec 2009 12:27:15 -0000
Received: (qmail 7510 invoked by uid 500); 27 Dec 2009 12:27:15 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 7439 invoked by uid 500); 27 Dec 2009 12:27:15 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@harmony.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@harmony.apache.org>
List-Post: <mailto:dev@harmony.apache.org>
List-Id: <dev.harmony.apache.org>
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 7428 invoked by uid 99); 27 Dec 2009 12:27:15 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 27 Dec 2009 12:27:15 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of tianwei.sheng@gmail.com
 designates 209.85.216.183 as permitted sender)
Received: from [209.85.216.183] (HELO mail-px0-f183.google.com)
 (209.85.216.183)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 27 Dec 2009 12:27:08 +0000
Received: by pxi13 with SMTP id 13so3049908pxi.24
        for <dev@harmony.apache.org>; Sun, 27 Dec 2009 04:26:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=UfA9lM13US45+Y0OADOhfyYLtWPyr2DW1j6SYl2fzwo=;
        b=ZrvBNnoZb7yT3GwRP9S/n61QPTo/Wqhp4Ir0ICg3gw80UMFp+m8j4TyCWLUsOTbG3X
         4DdjXLM0ZHzp/yoTa5iX/uCTfRrv3s2bOXInfoCClgImFFCZbdxIMZZY7aSaatLXND0X
         cIhqfMGSvBeGiaf9E9WqzvTiNL+RcPBUjxRTY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=lN1X8o73FyKsBW4SGi99VsB3Z7EnigDL+U4mQErbr2R+rTxVwu7GYmxN9SIrskiEy4
         MOITz1zma9Fhjec0RrszKZ/s/plxTlD88c73me/4FrsJ2esIzOwxP90hprgu23RD+hoq
         0zvGg0mC1D6BZ2hUdDqrTJsjr1kBWNJE14yaM=
MIME-Version: 1.0
Received: by 10.143.26.41 with SMTP id d41mr7406485wfj.13.1261916806578; Sun,
	27 Dec 2009 04:26:46 -0800 (PST)
In-Reply-To: <7618fe50912270359y4f2a2c2agbac312e20ad82f36@mail.gmail.com>
References: <7618fe50912020551s4d0984ccu52c3186e4c348a4c@mail.gmail.com>
	 <3b3f27c60912021701y3434884cv93f6d58d0871a5eb@mail.gmail.com>
	 <7618fe50912021831o2d5143ddxac2f2787fff4089c@mail.gmail.com>
	 <7618fe50912270359y4f2a2c2agbac312e20ad82f36@mail.gmail.com>
Date: Sun, 27 Dec 2009 20:26:46 +0800
Message-ID: <7618fe50912270426v7b9026eaw41c7c2bb765e71b@mail.gmail.com>
Subject: Re: The progress of MIPS patch work
From: Tianwei <tianwei.sheng@gmail.com>
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=001636e0af32fe04d5047bb4e678
X-Virus-Checked: Checked by ClamAV on apache.org

--001636e0af32fe04d5047bb4e678
Content-Type: text/plain; charset=ISO-8859-1

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.

--001636e0af32fe04d5047bb4e678--