From patchwork Mon Apr 2 12:24:37 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 150132 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 2978CB6EEB for ; Mon, 2 Apr 2012 22:25:08 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1333974309; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:From:To:Cc:Subject:References:Date:In-Reply-To: Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=FheZpcYp5EaCrcbK2hKvqqS1B8I=; b=NHG7HsTjKGEmrARzidaY9VqJPMfitPaaTTZBsJC2y4lKOVk5PfrQQUAw7MowlM 7Pnus4sfGPKQi32HalQ0nbBgfA0OWt0DgMIKm7u+rEqweM9FJeOxnPWea4G65kGF oOxMoYKAoDqiIQGKaGyjrVb8h4bu8iI6PwlQVfCaH/7CE= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=WIcwZ34EfpvTrytjSCCjMAu8rAdEcoYlxvmBMkrLvQH7HceyX2mXO6h2IH9DnF k95+UKEJ8ObiTGw6L31tQ7sehpn5hUXcwZ5DRrIrmM68l6p8OaOnjn1RC1MlBu/Z lIHZbIaYvJCT4ac292Dg+21fgQN3wmtm46DTQWft4wcpI=; Received: (qmail 1392 invoked by alias); 2 Apr 2012 12:24:58 -0000 Received: (qmail 1376 invoked by uid 22791); 2 Apr 2012 12:24:56 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, TW_IB, TW_XF, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS X-Spam-Check-By: sourceware.org Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 12:24:42 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 6B2A58D; Mon, 2 Apr 2012 14:24:41 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DngMlktf+Lfi; Mon, 2 Apr 2012 14:24:38 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 31F088C; Mon, 2 Apr 2012 14:24:38 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.5+Sun/8.14.5/Submit) id q32CObej005527; Mon, 2 Apr 2012 14:24:37 +0200 (MEST) From: Rainer Orth To: Steven Bosscher Cc: gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org, Richard Guenther , Eric Botcazou Subject: Re: [patch][rfa] Do not call output_constant from the front end References: <201203272307.17027.ebotcazou@adacore.com> Date: Mon, 02 Apr 2012 14:24:37 +0200 In-Reply-To: (Steven Bosscher's message of "Wed, 28 Mar 2012 00:23:09 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (usg-unix-v) MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Steven Bosscher writes: > Therefore, an RFA for the attached patch. Bootstrapped&tested on > powerpc64-unknown-linux-gnu. OK? Unfortunately, this patch completely broke libjava testing on i386-pc-solaris2* and x86_64-unknown-linux-gnu: all execution tests fail with a SEGV: Program received signal SIGSEGV, Segmentation fault. 0xfd0ddf7d in _Jv_Linker::verify_class (klass=klass@entry=0xfe945d80) at /vol/gcc/src/hg/trunk/local/libjava/link.cc:1904 1904 klass->engine->verify(klass); klass->engine is NULL at this point. Checking the generated .jcr sections, I found that a large number of them have sh_addralign 0x20 instead of 0x4 before your patch. This caused a massive reduction in the number of _Jv_RegisterClassHookDefault calls: With the following DTrace one-liner pid$target::_Jv_RegisterClassHookDefault:entry{ @[ustack()] = count(); } to investigate ArrayStore.exe execution, I find for the unpatched jc1: libgcj.so.13.0.0`_Jv_RegisterClassHookDefault libgcj.so.13.0.0`_Jv_RegisterClasses+0x44 libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E 0xe0ec 7213 With your patch, I get libgcj.so.13.0.0`_Jv_RegisterClassHookDefault libgcj.so.13.0.0`_Jv_RegisterNewClasses+0xb7 ArrayStore.exe`_Utf18 1 libgcj.so.13.0.0`_Jv_RegisterClassHookDefault libgcj.so.13.0.0`_Jv_RegisterClasses+0x44 libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E 0xe0ec 12 instead. The alignment change happens because LOCAL_ALIGNMENT overrides DECL_ALIGN. This can be avoided by setting DECL_USER_ALIGN (which unfortunately is undocumented). The result looks better, but still fails in a different way: Exception in thread "main" java.lang.NoClassDefFoundError: ArrayStore at java.lang.Class.initializeClass(libgcj.so.13.0.0) Caused by: java.lang.NullPointerException at java.lang.Class.initializeClass(libgcj.so.13.0.0) But the _Jv_RegisterClassHookDefault are almost back to normal: libgcj.so.13.0.0`_Jv_RegisterClassHookDefault libgcj.so.13.0.0`_Jv_RegisterClasses+0x44 libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class$E 0xe0ec 7212 I could trace this to a change in .jcr section flags: in ArrayStore.exe, I find Section Header[18]: sh_name: .jcr sh_addr: 0x8052058 sh_flags: [ SHF_ALLOC ] sh_size: 0x4 sh_type: [ SHT_PROGBITS ] sh_offset: 0x2058 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x4 Section Header[26]: sh_name: .jcr sh_addr: 0x80625e4 sh_flags: [ SHF_WRITE SHF_ALLOC ] sh_size: 0x4 sh_type: [ SHT_PROGBITS ] sh_offset: 0x25e4 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x4 The first (without SHF_WRITE set) is from jc1, the second from crtbegin.o. The Solaris linker (and probably other ELF linkers which don't special-case .jcr) merges sections not just by name, but only if name and attributs (flags, type) match. Not marking .jcr read-only fixes that part of the failure and restores libjava testsuite results on Solaris 11/x86 back to normal (no failures). Bootstrapped without regressions on i386-pc-solaris2.11. Ok for mainline? Rainer 2012-03-31 Rainer Orth * class.c (emit_register_classes_in_jcr_section): Set DECL_USER_ALIGN. Clear TREE_READONLY. # HG changeset patch # Parent ae1fe58e699b5ec26f0ad31675d3915eef63d963 Fix .jcr alignment diff --git a/gcc/java/class.c b/gcc/java/class.c --- a/gcc/java/class.c +++ b/gcc/java/class.c @@ -2815,10 +2815,11 @@ emit_register_classes_in_jcr_section (vo DECL_SECTION_NAME (cdecl) = build_string (strlen (JCR_SECTION_NAME), JCR_SECTION_NAME); DECL_ALIGN (cdecl) = POINTER_SIZE; + DECL_USER_ALIGN (cdecl) = 1; DECL_INITIAL (cdecl) = build_constructor (class_array_type, init); TREE_CONSTANT (DECL_INITIAL (cdecl)) = 1; TREE_STATIC (cdecl) = 1; - TREE_READONLY (cdecl) = 1; + TREE_READONLY (cdecl) = 0; TREE_CONSTANT (cdecl) = 1; DECL_ARTIFICIAL (cdecl) = 1; DECL_IGNORED_P (cdecl) = 1;