From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30264 invoked by alias); 6 Oct 2014 15:00:01 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 30236 invoked by uid 89); 6 Oct 2014 14:59:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_05,MEDICAL_SUBJECT,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 06 Oct 2014 14:59:58 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s96Exs94026844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 6 Oct 2014 10:59:54 -0400 Received: from zebedee.pink ([10.3.113.10]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s96ExqDf018986; Mon, 6 Oct 2014 10:59:52 -0400 Message-ID: <5432AE68.4030700@redhat.com> Date: Mon, 06 Oct 2014 15:00:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Chen Gang , Mike Stump CC: Michael Eager , Jeff Law , davem@redhat.com, gcc-patches List , java-patches@gcc.gnu.org Subject: Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern' References: <5430B7E8.1060001@gmail.com> <5430BBBE.8050905@gmail.com> <543215AE.7080206@gmail.com> <543254DB.9020600@redhat.com> <54329EEC.8040609@gmail.com> <54329F17.7050107@redhat.com> <5432A6C5.8040205@gmail.com> <5432A712.2080206@redhat.com> <5432AE7A.2060206@gmail.com> In-Reply-To: <5432AE7A.2060206@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q4/txt/msg00009.txt.bz2 On 10/06/2014 04:00 PM, Chen Gang wrote: > On 10/6/14 22:28, Andrew Haley wrote: >> On 10/06/2014 03:27 PM, Chen Gang wrote: >>> On 10/6/14 21:54, Andrew Haley wrote: >>>> On 10/06/2014 02:53 PM, Chen Gang wrote: >>>>> On 10/6/14 16:37, Andrew Haley wrote: >>>>>> On 06/10/14 05:08, Chen Gang wrote: >>>>>>> After try normal configure, get almost the same result, I guess, our >>>>>>> testsuite under Darwin x86_64 is OK. >>>>>>> >>>>>>> If no any additional reply within a week, I shall continue to try to >>>>>>> analyze the libjava Throw_2 issue. >>>>>> >>>>>> Throw_2 is a test specially contrived to detect segfaults that are >>>>>> not being correctly detected and turned into NullPointerException()s. >>>>>> A failure indicates that the segfault signal handler is broken. >>>>> >>>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'), >>>>> and after run it without any parameters, "1" is printed, but "2" is not >>>>> printed. >>>>> >>>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed), >>>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related >>>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}". >>>>> >>>>> And I shall continue to try to analyze it (within this month), and >>>>> welcome any additional ideas, suggestions, and completion for it, >>>> >>>> Not every platform supports unwinding through signal handlers. In x86 >>>> Linux there is some very clever code which interacts with the kernel to >>>> allow this. >>> >>> Excuse me, I am not quite familiar with Java, I guess what you said is: >>> >>> - The related feature need OS kernel support, if OS kernel does not >>> support, it may report "Abort trap: 6" or others. >>> >>> - And OS kernel has feature to support "1" printed does not mean it >>> also has feature to support "2" printed. >>> >>> - And I need try to make sure that my current Darwin kernel whether >>> supports it or not. >>> >>> If what I guess is incorrect, please let me know, thanks. >> >> That sounds approximately right, but it's changed a lot since I last >> looked. It may be that the magic is in glibc rather than the kernel. >> > > OK, thanks, I shall also notice about glibc when I try to analyze it, > e.g. need try to build and install upstream glibc instead of the Darwin > glibc (I am not quite sure whether I can do that, I guess I can). > > >>> For me, whether Darwin kernel supports or not, we have to improve >>> current implementation (may be testsuite configure or Makefile) to >>> avoid testsuite breaking. >> >> The testsuite isn't breaking: it's telling you something useful. >> > > Sorry it is breaked, at present, I temporarily skipped it and then can > let "make check" finish, the related temporarily skip diff may like > below (in real action, I modify the related Makefile, directly): You're missing what I'm saying. The testuite is not broken. You should be running "make -k check". Andrew.