------- Comment #2 from jakub at gcc dot gnu dot org 2010-03-08 15:12 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43290
