Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Richard Henderson <rth@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: Dwarf unwinder problems with store.exp and preserved regs
Date: Wed, 02 Jul 2003 19:19:00 -0000	[thread overview]
Message-ID: <20030702191907.GA26551@nevyn.them.org> (raw)
In-Reply-To: <20030702191059.GD1914@redhat.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


  reply	other threads:[~2003-07-02 19:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-01 21:44 Daniel Jacobowitz
2003-07-02  6:38 ` Andreas Jaeger
2003-07-02 19:11 ` Richard Henderson
2003-07-02 19:19   ` Daniel Jacobowitz [this message]
2003-07-02 21:33     ` Richard Henderson
2003-07-02 21:39       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030702191907.GA26551@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox