Summary: | ICE in dwarf2out_frame_debug_expr | ||
---|---|---|---|
Product: | gcc | Reporter: | Jakub Jelinek <jakub> |
Component: | debug | Assignee: | Jakub Jelinek <jakub> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gcc-bugs, hjl.tools, rhill |
Priority: | P3 | Keywords: | ice-on-valid-code |
Version: | 4.4.4 | ||
Target Milestone: | 4.5.0 | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2010-03-08 17:00:56 | |
Attachments: |
gcc44-pr43290-1.patch
gcc44-pr43290-2.patch gcc45-pr43290.patch gcc45-pr43290.patch |
Description
Jakub Jelinek
2010-03-08 14:45:16 UTC
Can you make it to fail on trunk or 4.4 branch since it could be caused by other changes on redhat/gcc-4_4-branch? If not, can you find out which change on redhat/gcc-4_4-branch causes this? I've tried, but haven't succeeded, that's why I said the bug is latent there. If we can prove this situation can't ever happen on 4.4 or 4.5 (4.5 on this testcase doesn't use a drap reg at all, so we'd need some other testcase where it does), then I'll of course do something on our branch only. But I believe this is just a general problem. BTW, even the 4.4 generated unwind info is bad: DW_CFA_advance_loc: 4 to 00000004 DW_CFA_def_cfa: r1 (ecx) ofs 0 DW_CFA_advance_loc: 9 to 0000000d DW_CFA_expression: r5 (ebp) (DW_OP_reg5) DW_CFA_advance_loc: 11 to 00000018 DW_CFA_def_cfa_expression (DW_OP_breg5: -16; DW_OP_deref) DW_CFA_advance_loc: 20 to 0000002c DW_CFA_expression: r7 (edi) (DW_OP_breg5: -4) DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8) DW_CFA_expression: r3 (ebx) (DW_OP_breg5: -12) 0: 8d 4c 24 04 lea 0x4(%esp),%ecx 4: 83 e4 e0 and $0xffffffe0,%esp 7: ff 71 fc pushl -0x4(%ecx) a: 55 push %ebp b: 89 e5 mov %esp,%ebp d: 83 ec 78 sub $0x78,%esp 10: 89 5c 24 6c mov %ebx,0x6c(%esp) 14: 89 4c 24 68 mov %ecx,0x68(%esp) 18: 89 74 24 70 mov %esi,0x70(%esp) 1c: 89 7c 24 74 mov %edi,0x74(%esp) 20: e8 00 00 00 00 call 25 <_ZNSt13basic_filebufIcSt11char_traitsIcEE7seekposESt4fposI9mbstate_tEN12_GLOBAL__N_113_Ios_OpenmodeE+0x25> 25: 5b pop %ebx 26: 81 c3 03 00 00 00 add $0x3,%ebx 28: R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 2c: 8b 31 mov (%ecx),%esi 2e: 89 4d c4 mov %ecx,-0x3c(%ebp) 1) Saying that %r5 (ebp) is saved in DW_OP_reg5 looks quite redundant to me. 2) More importantly, %ebx is said to be saved in DW_OP_breg5 - 12 only after add $0x3, %ebx, so when e.g. a debugger stops in between pop %ebx and add $3, %ebx, it will think caller's %ebx still lives in %ebx register, which is wrong. (In reply to comment #2) > I've tried, but haven't succeeded, that's why I said the bug is latent there. > If we can prove this situation can't ever happen on 4.4 or 4.5 (4.5 on this > testcase doesn't use a drap reg at all, so we'd need some other testcase where > it does), then I'll of course do something on our branch only. But I believe > this is just a general problem. BTW, even the 4.4 generated unwind info is > bad: Can you make a run-time testcase out of it? Ah, the %ebp saved in DW_OP_reg5 is just a 4.4 bug, fixed by http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00235.html (the fix is in 4.5 and 4.4-RH). Saying that %ebp is saved in DW_OP_breg5 0 is correct and desirable. (In reply to comment #4) > Ah, the %ebp saved in DW_OP_reg5 is just a 4.4 bug, fixed by > http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00235.html (the fix is in 4.5 and > 4.4-RH). Saying that %ebp is saved in DW_OP_breg5 0 is correct and desirable. > Can we backport it to 4.4? Not sure if there haven't been follow-ups. There were at least 100 changes to dwarf2out.c since 4.4 release, and at least 10 of them were related to the indirect vs. direct stuff. Created attachment 20043 [details] gcc44-pr43290-1.patch One alternative fix that cures this testcase on redhat/gcc-4_4-branch. Created attachment 20044 [details] gcc44-pr43290-2.patch Another fix. Wonder why that insn is marked as frame related at all, for the drap saving the spill (and restore) generated by ix86_expand_prologue/ix86_expand_epilogue should be the canonical one, after all where the vDRAP was spilled to is something that could be clobbered before the epilogue if vDRAP starts living in the register again, etc. (In reply to comment #8) > Created an attachment (id=20044) [edit] > gcc44-pr43290-2.patch > > Another fix. Wonder why that insn is marked as frame related at all, for the > drap saving the spill (and restore) generated by > ix86_expand_prologue/ix86_expand_epilogue should be the canonical one, after > all where the vDRAP was spilled to is something that could be clobbered before > the epilogue if vDRAP starts living in the register again, etc. > There may be a reason to do so at the time. If there are no regressions in gcc testsuite, it probably is OK not to mark drap as frame related. I'll test it, both on the trunk and 4.4-RH. BTW, I've moved the 2) issue to PR43293. Subject: Bug 43290 Author: jakub Date: Tue Mar 9 18:48:43 2010 New Revision: 157313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157313 Log: PR debug/43290 * config/i386/i386.c (ix86_get_drap_rtx): Don't set RTX_FRAME_RELATED_P. * g++.dg/eh/unwind2.C: New test. Added: trunk/gcc/testsuite/g++.dg/eh/unwind2.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog Fixed for 4.5+. (In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=20044) [edit] > > gcc44-pr43290-2.patch > > > > Another fix. Wonder why that insn is marked as frame related at all, for the > > drap saving the spill (and restore) generated by > > ix86_expand_prologue/ix86_expand_epilogue should be the canonical one, after > > all where the vDRAP was spilled to is something that could be clobbered before > > the epilogue if vDRAP starts living in the register again, etc. > > > > There may be a reason to do so at the time. If there are no > regressions in gcc testsuite, it probably is OK not to mark > drap as frame related. > It is for PR 36728. Is there a way to add debug testcases from PR 36728 to gcc testsuite? Yes, sticking them in gcc/testsuite/gcc.dg/guality/ and using /* { dg-final { gdb-test <line> "<varname>" "<expectedvalue>" } } */ If my patch really broke that, then I think we'll need to use some REG_CFA_* note or something similar to be able to differentiate between this vDRAP = DRAP insn and saving DRAP into a prologue save slot. Created attachment 20072 [details] gcc45-pr43290.patch Untested patch. (In reply to comment #15) > Yes, sticking them in gcc/testsuite/gcc.dg/guality/ and using > /* { dg-final { gdb-test <line> "<varname>" "<expectedvalue>" } } */ > > If my patch really broke that, then I think we'll need to use some REG_CFA_* > note or something similar to be able to differentiate between this vDRAP = DRAP > insn and saving DRAP into a prologue save slot. > I will add some testcases for PR 36728 to make sure that it isn't broken. Created attachment 20073 [details] gcc45-pr43290.patch Updated patch. This one includes testcases, and also fixes for -O+, when optimizing we really shouldn't be replacing random registers that once happened to be vDRAP or DRAP somewhere with DW_OP_fbreg and there is no point tracking it at all - after all when optimizing combiner or some other optimization pass will very likely remove the vDRAP = DRAP insn anyway. For -O1+ var-tracking is supposed to do the right job finding where the variable lives. Subject: Bug 43290 Author: jakub Date: Wed Mar 10 18:17:10 2010 New Revision: 157363 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157363 Log: PR debug/43290 * reg-notes.def (REG_CFA_SET_VDRAP): New note. * dwarf2out.c (dwarf2out_frame_debug_expr): Remove rule 20 - setting of fde->vdrap_reg. (dwarf2out_frame_debug): Handle REG_CFA_SET_VDRAP note. (based_loc_descr): Only express drap or vdrap regno based expressions using DW_OP_fbreg when not optimizing. * config/i386/i386.c (ix86_get_drap_rtx): When not optimizing, make the vDRAP = DRAP assignment RTX_FRAME_RELATED_P and add REG_CFA_SET_VDRAP note. PR debug/36728 * gcc.dg/guality/pr36728-1.c: New test. * gcc.dg/guality/pr36728-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr36728-1.c trunk/gcc/testsuite/gcc.dg/guality/pr36728-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/dwarf2out.c trunk/gcc/reg-notes.def trunk/gcc/testsuite/ChangeLog We're hitting this on vanilla 4.4.5. Any chance of a backport? https://bugs.gentoo.org/357287 this is an in-branch regression from 4.4.4 and prevents -march=native bootstrap on Sandy Bridge. want a new bug? And now 4.4.6. |