Re: Dwarf unwinder problems with store.exp and preserved regs

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Jul 02, 2003 at 12:10:59PM -0700, Richard Henderson wrote:
> On Tue, Jul 01, 2003 at 05:44:30PM -0400, Daniel Jacobowitz wrote:
> > However, GCC only emits information about the CFA, not about the default
> > saved-ness of registers.  So we get:
> > 
> > 168       /* Initialize newly allocated registers.  */
> > 169       memset (rs->reg + rs->num_regs, 0, (num_regs - rs->num_regs) * size);
> > 
> > And 0 is UNDEFINED.  So $ebx - a call-saved register on i386 - shows up as
> > undefined.
> 
> I think this is your bug.
> 
> >   - Fix GCC.  I -believe-, from reading the spec, that GCC is to blame for
> >     not emiting this information.
> 
> No, what GCC doesn't provide is clobber information.  It *does* 
> provide save information.  GDB should be assuming the register
> is valid in the previous frame unless it sees DW_CFA_undefined.
> 
> Leastwise, that's certainly what gcc's frame unwinder assumes,
> and I don't see anything that contradicts this in the standard.

If we assume that the register is valid in the previous frame, we'll go
back to printing out a lot of garbage.  Consider:

0804833d <add_short>:
 804833d:       55                      push   %ebp
 804833e:       89 e5                   mov    %esp,%ebp
 8048340:       8b 45 08                mov    0x8(%ebp),%eax
 8048343:       8b 55 0c                mov    0xc(%ebp),%edx
 8048346:       89 c1                   mov    %eax,%ecx
 8048348:       89 d0                   mov    %edx,%eax
 804834a:       8d 04 08                lea    (%eax,%ecx,1),%eax
 804834d:       98                      cwtl   
 804834e:       c9                      leave  
 804834f:       c3                      ret    

The CFI for this:
  DW_CFA_advance_loc: 1 to 0804833e
  DW_CFA_def_cfa_offset: 8
  DW_CFA_offset: r5 at cfa-8
  DW_CFA_advance_loc: 2 to 08048340
  DW_CFA_def_cfa_reg: r5

So if the initial row assumes all registers are valid, we'd print out a
value in the caller's $eax incorrectly.  The false negatives will go
away and be replaced by false positives.

This information needs to come from somewhere.  Even if GDB has to
derive it from the ABI.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer