public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb@sources.redhat.com
Subject: Dwarf unwinder problems with store.exp and preserved regs
Date: Tue, 01 Jul 2003 21:44:00 -0000	[thread overview]
Message-ID: <20030701214429.GA3913@nevyn.them.org> (raw)

I see two kinds of failures in store.exp right now, on the two targets I'm
testing.  On i386, with DWARF 2 unwinding, I see spurious <value optimized
out> messages; and on ARM (without DWARF 2 unwinding) I see legitimately
corrupted values.  The latter are easy, so I'll send a patch momentarily. 
The former are more interesting.

Here's the problem: the unwinder does not know what registers are considered
call saved.  GDB reads some initial CIE unwind information from the debug
file:

  /* Instruction sequence to initialize a register set.  */
  unsigned char *initial_instructions;

  /* True if a 'z' augmentation existed.  */
  unsigned char saw_z_augmentation;

      cie->saw_z_augmentation = (*augmentation == 'z');
      if (cie->saw_z_augmentation)
        {
          ULONGEST length;

          length = read_unsigned_leb128 (unit->abfd, buf, &bytes_read);
          buf += bytes_read;
          cie->initial_instructions = buf + length;
          augmentation++;
        }

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.

There are two things we can do about this, I think, and perhaps we should
do both:
  - Fix GCC.  I -believe-, from reading the spec, that GCC is to blame for
    not emiting this information.
  - Provide an architecture method to pre-initialize the register table
    before initial_instructions is evaluated.

Thoughts?
-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

             reply	other threads:[~2003-07-01 21:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-01 21:44 Daniel Jacobowitz [this message]
2003-07-02  6:38 ` Andreas Jaeger
2003-07-02 19:11 ` Richard Henderson
2003-07-02 19:19   ` Daniel Jacobowitz
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=20030701214429.GA3913@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).