From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3973 invoked by alias); 2 Apr 2012 12:29:13 -0000 Received: (qmail 3952 invoked by uid 22791); 2 Apr 2012 12:29:10 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_IB,TW_XF X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 12:28:54 +0000 Received: by yenm3 with SMTP id m3so1145717yen.20 for ; Mon, 02 Apr 2012 05:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.100.162 with SMTP id ez2mr5161902igb.20.1333369732982; Mon, 02 Apr 2012 05:28:52 -0700 (PDT) Received: by 10.42.228.200 with HTTP; Mon, 2 Apr 2012 05:28:52 -0700 (PDT) In-Reply-To: References: <201203272307.17027.ebotcazou@adacore.com> Date: Mon, 02 Apr 2012 12:29:00 -0000 Message-ID: Subject: Re: [patch][rfa] Do not call output_constant from the front end From: Richard Guenther To: Rainer Orth Cc: Steven Bosscher , gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org, Eric Botcazou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 X-SW-Source: 2012-q2/txt/msg00001.txt.bz2 On Mon, Apr 2, 2012 at 2:24 PM, Rainer Orth w= rote: > 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=3Dklass@entry=3D0xfe945d80) > =A0 =A0at /vol/gcc/src/hg/trunk/local/libjava/link.cc:1904 > 1904 =A0 =A0 =A0klass->engine->verify(klass); > > klass->engine is NULL at this point. =A0Checking the generated .jcr > sections, I found that a large number of them have sh_addralign 0x20 > instead of 0x4 before your patch. =A0This caused a massive reduction in > the number of _Jv_RegisterClassHookDefault calls: > > With the following DTrace one-liner > > pid$target::_Jv_RegisterClassHookDefault:entry{ @[ustack()] =3D count(); } > > to investigate ArrayStore.exe execution, I find for the unpatched jc1: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClassHookDefault > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClasses+0x44 > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class= $E > =A0 =A0 =A0 =A0 =A0 =A0 =A00xe0ec > =A0 =A0 =A0 =A0 =A0 =A0 7213 > > With your patch, I get > > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClassHookDefault > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterNewClasses+0xb7 > =A0 =A0 =A0 =A0 =A0 =A0 =A0ArrayStore.exe`_Utf18 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01 > > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClassHookDefault > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClasses+0x44 > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class= $E > =A0 =A0 =A0 =A0 =A0 =A0 =A00xe0ec > =A0 =A0 =A0 =A0 =A0 =A0 =A0 12 > > instead. > > The alignment change happens because LOCAL_ALIGNMENT overrides > DECL_ALIGN. =A0This can be avoided by setting DECL_USER_ALIGN (which > unfortunately is undocumented). =A0The result looks better, but still > fails in a different way: > > Exception in thread "main" java.lang.NoClassDefFoundError: ArrayStore > =A0 at java.lang.Class.initializeClass(libgcj.so.13.0.0) > Caused by: java.lang.NullPointerException > =A0 at java.lang.Class.initializeClass(libgcj.so.13.0.0) > > But the _Jv_RegisterClassHookDefault are almost back to normal: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClassHookDefault > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_Jv_RegisterClasses+0x44 > =A0 =A0 =A0 =A0 =A0 =A0 =A0libgcj.so.13.0.0`_ZN4java4lang9Cloneable6class= $E > =A0 =A0 =A0 =A0 =A0 =A0 =A00xe0ec > =A0 =A0 =A0 =A0 =A0 =A0 7212 > > I could trace this to a change in .jcr section flags: in ArrayStore.exe, > I find > > Section Header[18]: =A0sh_name: .jcr > =A0 =A0sh_addr: =A0 =A0 =A00x8052058 =A0 =A0 =A0 sh_flags: =A0 [ SHF_ALLO= C ] > =A0 =A0sh_size: =A0 =A0 =A00x4 =A0 =A0 =A0 =A0 =A0 =A0 sh_type: =A0 =A0[ = SHT_PROGBITS ] > =A0 =A0sh_offset: =A0 =A00x2058 =A0 =A0 =A0 =A0 =A0sh_entsize: 0 > =A0 =A0sh_link: =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sh_info: =A0 =A00 > =A0 =A0sh_addralign: 0x4 > > Section Header[26]: =A0sh_name: .jcr > =A0 =A0sh_addr: =A0 =A0 =A00x80625e4 =A0 =A0 =A0 sh_flags: =A0 [ SHF_WRIT= E SHF_ALLOC ] > =A0 =A0sh_size: =A0 =A0 =A00x4 =A0 =A0 =A0 =A0 =A0 =A0 sh_type: =A0 =A0[ = SHT_PROGBITS ] > =A0 =A0sh_offset: =A0 =A00x25e4 =A0 =A0 =A0 =A0 =A0sh_entsize: 0 > =A0 =A0sh_link: =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sh_info: =A0 =A00 > =A0 =A0sh_addralign: 0x4 > > The first (without SHF_WRITE set) is from jc1, the second from > crtbegin.o. =A0The 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. =A0Not 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? Ok. I wonder what happens if we mark __JCR_END__ in crtstuff.c as const? Thanks, Richard. > =A0 =A0 =A0 =A0Rainer > > > 2012-03-31 =A0Rainer Orth =A0 > > =A0 =A0 =A0 =A0* class.c (emit_register_classes_in_jcr_section): Set DECL= _USER_ALIGN. > =A0 =A0 =A0 =A0Clear TREE_READONLY. > > > > -- > -------------------------------------------------------------------------= ---- > Rainer Orth, Center for Biotechnology, Bielefeld University >