Patchwork [rfa] Do not call output_constant from the front end

login
register
mail settings
Submitter Rainer Orth
Date April 2, 2012, 12:24 p.m.
Message ID <yddzkaus4my.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
Download mbox | patch
Permalink /patch/150132/
State New
Headers show

Comments

Rainer Orth - April 2, 2012, 12:24 p.m.
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?

	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.
Richard Guenther - April 2, 2012, 12:28 p.m.
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
>

Patch

# 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;