From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: pierre.muller@ics-cnrs.unistra.fr (Pierre Muller)
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: [RFC] PR gdb/17445 fix
Date: Thu, 06 Nov 2014 17:55:00 -0000 [thread overview]
Message-ID: <201411061755.sA6Ht8sh025070@d03av02.boulder.ibm.com> (raw)
In-Reply-To: <005301cfdd4b$aefd3830$0cf7a890$@muller@ics-cnrs.unistra.fr> from "Pierre Muller" at Oct 01, 2014 09:45:32 AM
Pierre Muller wrote:
> * gdb/dwarf2-frame.c (dwarf2_frame_cache): Avoid double handling of
> return address column.
Commenting just on the GDB part, this seems incorrect:
> /* Use the GDB register number as the destination index. */
> int regnum = gdbarch_dwarf2_reg_to_regnum (gdbarch, column);
>
> + /* Do not handle return address here, it is done in the next
> + loop. This also avoids problem with pei-x86-64 target
> + having retaddr_column set to 32 (which is xmm15). */
> + if (column == fs->retaddr_column)
> + continue;
> /* If there's no corresponding GDB register, ignore it. */
> if (regnum < 0 || regnum >= num_regs)
> continue;
The "next loop" does not handle the return address. It handles *other*
registers that *refer* to the return address.
Usually, you have a "return address column" in DWARF, which may or may
not itself refer to a register of the platform, and then you have some
other rule (either explicit or implicitly defined by the ABI) where the
PC refers to the return address column. Conceptually, unwinding is
performed in two parts: first, the return address is computed following
the instructions for the return address column, and then the PC is set
to the unwound return address value (or some value derived from it).
On some platforms, the return address itself does not correspond to any
register, and is *only* used for setting the PC. On some other platforms,
the return address itself corresponds to an actual hardware register, and
the unwind instructions for the return address column are in fact also
used to determine the unwound value of that register.
The latter is the case e.g. on s390, where %r14 is used as return address
column. The unwind instructions for %r14 are used both to unwind the
actual value of %r14, and to unwind the value of the PC.
Your patch would break that usage since you now no longer apply the
contents of the return address column to unwind register %r14 on s390.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
prev parent reply other threads:[~2014-11-06 17:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 7:45 Pierre Muller
2014-11-06 9:13 ` PING [PATCH RFC] " Pierre Muller
2014-11-06 17:55 ` Ulrich Weigand [this message]
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=201411061755.sA6Ht8sh025070@d03av02.boulder.ibm.com \
--to=uweigand@de.ibm.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=pierre.muller@ics-cnrs.unistra.fr \
/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).