Re: Support Dwarf3 DW_CFA_val_* expressions

[Daniel Jacobowitz <drow@false.org>]

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