From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32028 invoked by alias); 18 Nov 2010 16:18:07 -0000 Received: (qmail 32005 invoked by uid 22791); 18 Nov 2010 16:18:05 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_DD,TW_IB,TW_OV X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Nov 2010 16:18:01 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/46515] [4.6 Regression] Many libjava failures X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.0 X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 18 Nov 2010 16:21:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg02368.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2010.11.18 16:17:40 CC| |jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek 2010-11-18 16:17:40 UTC --- This seems to be wrong unwind info for _ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi, at least backtrace like: #24 0x00007ffff5f73df2 in _Jv_Linker::resolve_pool_entry (klass=0x7fffeeb91618, index=2, lazy=true) at ../../../libjava/link.cc:440 #25 0x00007ffff5f74158 in _Jv_Linker::ensure_class_linked (klass=0x7fffeeb91618) at ../../../libjava/link.cc:1748 #26 0x00007ffff5f72a20 in _Jv_Linker::wait_for_state (klass=0x7fffeeb91618, state=9) at ../../../libjava/link.cc:2076 #27 0x00007ffff5f737a8 in _Jv_Linker::get_interfaces (klass=0x7fffeeb91af8, ifaces=0x7fffffffdbd0) at ../../../libjava/link.cc:777 #28 0x00007ffff5f74357 in _Jv_Linker::prepare_constant_time_tables (klass=0x7fffeeb91af8) at ../../../libjava/link.cc:716 #29 0x00007ffff5f72b08 in _Jv_Linker::wait_for_state (klass=0x7fffeeb91af8, state=7) at ../../../libjava/link.cc:2067 #30 0x0000000000000003 in ?? () #31 0x00007ffff5f733b6 in _Jv_Linker::link_symbol_table (klass=0x0) at ../../../libjava/link.cc:1308 #32 0x00007ffff5f72a30 in _Jv_Linker::wait_for_state (klass=0x7fffeeb913a8, state=9) at ../../../libjava/link.cc:2078 #33 0x00007ffff5fa77e3 in java::lang::Class::initializeClass (this=0x7fffeeb913a8) at ../../../libjava/java/lang/natClass.cc:720 suggests there (note the weird ra 0x00000003 in it). GDB doesn't crash on it, but the libgcc unwinder does. The code difference from yesterday in that routine is: 193f: 0f 84 79 fe ff ff je 17be <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1e> 1945: e8 00 00 00 00 callq 194a <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1aa> 1946: R_X86_64_PLT32 _Z20_Jv_GetCurrentJNIEnvv-0x4 - 194a: 48 83 c4 08 add $0x8,%rsp - 194e: 48 89 d9 mov %rbx,%rcx - 1951: 4c 89 ee mov %r13,%rsi - 1954: 5b pop %rbx - 1955: 5d pop %rbp - 1956: 41 5c pop %r12 - 1958: 41 5d pop %r13 - 195a: 41 5e pop %r14 - 195c: 41 5f pop %r15 - 195e: 48 89 c2 mov %rax,%rdx - 1961: bf 38 00 00 00 mov $0x38,%edi - 1966: 31 c0 xor %eax,%eax - 1968: e9 00 00 00 00 jmpq 196d <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1cd> - 1969: R_X86_64_PLT32 _Z19_Jv_JVMTI_PostEvent10jvmtiEventPN4java4lang6ThreadEz-0x4 - 196d: 0f 1f 00 nopl (%rax) + 194a: 41 58 pop %r8 + 194c: 48 89 d9 mov %rbx,%rcx + 194f: 4c 89 ee mov %r13,%rsi + 1952: 48 89 c2 mov %rax,%rdx + 1955: 5b pop %rbx + 1956: 5d pop %rbp + 1957: 41 5c pop %r12 + 1959: 41 5d pop %r13 + 195b: 41 5e pop %r14 + 195d: 41 5f pop %r15 + 195f: bf 38 00 00 00 mov $0x38,%edi + 1964: 31 c0 xor %eax,%eax + 1966: e9 00 00 00 00 jmpq 196b <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1cb> + 1967: R_X86_64_PLT32 _Z19_Jv_JVMTI_PostEvent10jvmtiEventPN4java4lang6ThreadEz-0x4 + 196b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 1970: 48 89 df mov %rbx,%rdi 1973: e8 00 00 00 00 callq 1978 <_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1d8> 1974: R_X86_64_PLT32 _ZN10_Jv_Linker28ensure_method_table_completeEPN4java4lang5ClassE-0x4 (i.e. replacement of addq $8, %rsp with popq %r8 and movq %rax, %rdx scheduled elsewhere). And unwind info difference is: DW_CFA_advance_loc: 4 to 000017d0 DW_CFA_restore_state - DW_CFA_advance_loc2: 382 to 0000194e - DW_CFA_remember_state + DW_CFA_advance_loc2: 380 to 0000194c DW_CFA_def_cfa_offset: 56 - DW_CFA_advance_loc: 7 to 00001955 + DW_CFA_advance_loc: 10 to 00001956 + DW_CFA_remember_state DW_CFA_def_cfa_offset: 48 - DW_CFA_advance_loc: 1 to 00001956 + DW_CFA_advance_loc: 1 to 00001957 DW_CFA_def_cfa_offset: 40 - DW_CFA_advance_loc: 2 to 00001958 + DW_CFA_advance_loc: 2 to 00001959 DW_CFA_def_cfa_offset: 32 - DW_CFA_advance_loc: 2 to 0000195a + DW_CFA_advance_loc: 2 to 0000195b DW_CFA_def_cfa_offset: 24 - DW_CFA_advance_loc: 2 to 0000195c + DW_CFA_advance_loc: 2 to 0000195d DW_CFA_def_cfa_offset: 16 - DW_CFA_advance_loc: 2 to 0000195e + DW_CFA_advance_loc: 2 to 0000195f DW_CFA_def_cfa_offset: 8 - DW_CFA_advance_loc: 18 to 00001970 + DW_CFA_advance_loc: 17 to 00001970 DW_CFA_restore_state Except for the expected DW_CFA_advance_loc changes, the important difference is that before Richard's patch DW_CFA_remember_state preceeded DW_CFA_def_cfa_offset 56 right after the add $8, %rsp insn, while with Richard's patch DW_CFA_remember_state appears only after it. I'll preprocess link.cc now and will see what is gong on at the RTL level...