Re: [patch][rfa] Do not call output_constant from the front end
Steven Bosscher stevenb@gmail.com writes:
Therefore, an RFA for the attached patch. Bootstrappedtested 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 r...@cebitec.uni-bielefeld.de
* 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;
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch][rfa] Do not call output_constant from the front end
On Mon, Apr 2, 2012 at 2:24 PM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
Steven Bosscher stevenb@gmail.com writes:
Therefore, an RFA for the attached patch. Bootstrappedtested 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 r...@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
Re: [patch][rfa] Do not call output_constant from the front end
On Wed, Mar 28, 2012 at 12:02 PM, Richard Guenther richard.guent...@gmail.com wrote: Therefore, an RFA for the attached patch. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK? Ok. Thanks. Committed as r185977. Ciao! Steven
