From: Andreas Jaeger <aj@suse.de>
To: gdb@sources.redhat.com
Cc: Josef Zlomek <zlomj9am@artax.karlin.mff.cuni.cz>
Subject: Re: Dwarf unwinder problems with store.exp and preserved regs
Date: Wed, 02 Jul 2003 06:38:00 -0000 [thread overview]
Message-ID: <hoy8zhqvpp.fsf@byrd.suse.de> (raw)
In-Reply-To: <20030701214429.GA3913@nevyn.them.org> (Daniel Jacobowitz's message of "Tue, 1 Jul 2003 17:44:30 -0400")
Daniel Jacobowitz <drow@mvista.com> writes:
> 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.
I see the same problem on x86-64 with the <value optimized out> messages.
> 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.
I think the later is the way to go - but didn't read the spec fully to
give an authoritative answer,
Andreas
--
Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
next prev parent reply other threads:[~2003-07-02 6:38 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 [this message]
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=hoy8zhqvpp.fsf@byrd.suse.de \
--to=aj@suse.de \
--cc=gdb@sources.redhat.com \
--cc=zlomj9am@artax.karlin.mff.cuni.cz \
/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