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
next prev parent 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