This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Support Dwarf3 DW_CFA_val_* expressions
On Sun, Mar 12, 2006 at 11:25:41PM -0300, Alexandre Oliva wrote:
> On Mar 11, 2006, Daniel Jacobowitz <drow@false.org> wrote:
>
> > On Tue, Mar 07, 2006 at 02:46:00PM -0300, Alexandre Oliva wrote:
> >> Using the address of the first instruction in the region wouldn't work
> >> either. The hand-generated unwind info arranges for _L_mutex_lock_31
> >> on i386 to seem like it calls itself, for some reason I don't quite
> >> understand. Jakub says the backtrace we get after my change is
> >> correct, whereas *without* the patch we get this:
>
> > Where does this hand generated unwind info come from?
>
> Jakub's testcase submitted as part of the patch.
OK, you and I were using "entry into a new frame" differently.
Here's the function:
8048584: 8b 75 08 mov 0x8(%ebp),%esi
8048587: 8d 9d f8 fe ff ff lea 0xfffffef8(%ebp),%ebx
804858d: 85 f6 test %esi,%esi
804858f: 75 7c jne 804860d <_L_mutex_lock_156>
8048591: 81 c4 00 01 00 00 add $0x100,%esp
...
0804860d <_L_mutex_lock_156>:
804860d: 8d 4d 08 lea 0x8(%ebp),%ecx
8048610: e8 4b ff ff ff call 8048560 <bar>
8048615: e9 77 ff ff ff jmp 8048591 <foo+0x18>
Here's the frame info:
00000014 0000002c 00000018 FDE cie=00000000 pc=0804860d..0804861a
DW_CFA_val_expression: r8 (DW_OP_breg8: 8)
DW_CFA_advance_loc: 3 to 08048610
DW_CFA_val_expression: r8 (DW_OP_breg8: 5)
DW_CFA_advance_loc: 4 to 08048614
DW_CFA_val_expression: r8 (DW_OP_breg8: 6; DW_OP_const4s: -382; DW_OP_minus; DW_OP_const4s: -520; DW_OP_plus)
DW_CFA_nop
DW_CFA_nop
r8 is the return address column. That's %eip. So for the first two
instructions of this "function", we claim that we return to the jump
instruction. If you're going to put that in the unwind information,
why shouldn't you expect GDB to show the jump as the next address in
the backtrace?
[Why the second one advances loc by 4 bytes instead of 5 I don't know.
It looks like it might be a bug in the version of gas I used; the test
looks OK.]
Then, at the jump, the PC is unwound to PC + 6 - (-382) + (-520) [for
reasons involving the difference of labels in different sections,
AFAICT]. That puts us back where we came from.
I assume these hoops are jumped through to reduce the size of the debug
info, while maintaining its PIC-ness. Gotta be a better way... but I
don't see any reason why, given this unwind info, GDB should not
display the frame twice.
Which I think means some version of your patch already posted is
correct, minus any arguments about the test cases, but I'm no longer
quite sure which version.
--
Daniel Jacobowitz
CodeSourcery