From: Richard Guenther <richard.guenther@gmail.com>
To: Rainer Orth <ro@cebitec.uni-bielefeld.de>
Cc: Steven Bosscher <stevenb.gcc@gmail.com>,
gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org,
Eric Botcazou <ebotcazou@adacore.com>
Subject: Re: [patch][rfa] Do not call output_constant from the front end
Date: Mon, 02 Apr 2012 12:29:00 -0000 [thread overview]
Message-ID: <CAFiYyc1o0ZabmF39rMiqkwLzARFXYE_G0LpL=B3UG7YLFN=hAg@mail.gmail.com> (raw)
In-Reply-To: <yddzkaus4my.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
On Mon, Apr 2, 2012 at 2:24 PM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Steven Bosscher <stevenb.gcc@gmail.com> 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?
Ok. I wonder what happens if we mark __JCR_END__ in crtstuff.c
as const?
Thanks,
Richard.
> Rainer
>
>
> 2012-03-31 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
>
> * class.c (emit_register_classes_in_jcr_section): Set DECL_USER_ALIGN.
> Clear TREE_READONLY.
>
>
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
prev parent reply other threads:[~2012-04-02 12:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-27 20:36 [patch] " Steven Bosscher
2012-03-27 21:07 ` Eric Botcazou
2012-03-27 21:52 ` Steven Bosscher
2012-03-27 22:23 ` [patch][rfa] " Steven Bosscher
2012-03-28 7:46 ` Andrew Haley
2012-03-28 10:02 ` Richard Guenther
2012-03-29 21:04 ` Steven Bosscher
2012-04-02 12:24 ` Rainer Orth
2012-04-02 12:29 ` Richard Guenther [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFiYyc1o0ZabmF39rMiqkwLzARFXYE_G0LpL=B3UG7YLFN=hAg@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=java-patches@gcc.gnu.org \
--cc=ro@cebitec.uni-bielefeld.de \
--cc=stevenb.gcc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).