From: "H.J. Lu" <hjl.tools@gmail.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: PING: PATCH: PR backtrace/14646: [x32] backtrace doesn't work
Date: Wed, 03 Oct 2012 15:59:00 -0000 [thread overview]
Message-ID: <CAMe9rOo9Pdc=2y_1bmJ4ER-K2r-trS2SD+W7QsWbT-8KGDr4hw@mail.gmail.com> (raw)
In-Reply-To: <201210031543.q93FhTPo021324@glazunov.sibelius.xs4all.nl>
On Wed, Oct 3, 2012 at 8:43 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Wed, 3 Oct 2012 08:26:34 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> On Sun, Sep 30, 2012 at 2:40 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > Hi,
>> >
>> > amd64_x32_init_abi has
>> >
>> > tdep->sp_regnum_from_eax = AMD64_RSP_REGNUM;
>> > tdep->pc_regnum_from_eax = AMD64_RIP_REGNUM;
>> >
>> > But unwind frame info is based on the real RSP/RIP
>> > registers. Pseudo sp/pc registers don't work with
>> > frame related codes:
>> >
>> > [hjl@gnu-tools-1 gdb]$ egrep "pc_regnum|sp_regnum" *fram*.c
>> > dwarf2-frame.c: if (regnum == gdbarch_pc_regnum (gdbarch))
>> > dwarf2-frame.c: else if (regnum == gdbarch_sp_regnum (gdbarch))
>> > dwarf2-frame.c: == gdbarch_sp_regnum (gdbarch)))
>> > dwarf2-frame-tailcall.c: if (regnum == gdbarch_pc_regnum
>> > (this_gdbarch))
>> > dwarf2-frame-tailcall.c: else if (cache->prev_sp_p && regnum ==
>> > gdbarch_sp_regnum (this_gdbarch))
>> > dwarf2-frame-tailcall.c: int sp_regnum;
>> > dwarf2-frame-tailcall.c: sp_regnum = gdbarch_sp_regnum
>> > (prev_gdbarch);
>> > dwarf2-frame-tailcall.c: if (sp_regnum == -1)
>> > dwarf2-frame-tailcall.c: prev_sp = frame_unwind_register_unsigned
>> > (this_frame, sp_regnum);
>> > frame.c: && gdbarch_pc_regnum (gdbarch) >= 0
>> > frame.c: gdbarch_pc_regnum (gdbarch),
>> > frame.c: gdbarch_pc_regnum (gdbarch),
>> > frame.c: the gdbarch_sp_regnum register is meaningful. */
>> > frame.c: if (gdbarch_sp_regnum (gdbarch) >= 0)
>> > frame.c: gdbarch_sp_regnum (gdbarch));
>> > [hjl@gnu-tools-1 gdb]$
>> >
>> > It is nice to print
>> >
>> > (gdb) p $sp
>> > $1 = (void *) 0xffffd028
>> >
>> > instead of
>> >
>> > (gdb) p $sp
>> > $1 = 4294955048
>> >
>> > But it breaks frame unwind. This patch removes pseudo sp/pc regnum from
>> > x32. "p $sp" and "p $pc" will print 64bit integers. But "p $esp" and
>> > "p $esp" work fine. OK for trunk and 4.5 branch?
>> >
>> > Thanks.
>> >
>> >
>> > H.J.
>> > ---
>> > 2012-09-30 H.J. Lu <hongjiu.lu@intel.com>
>> >
>> > PR backtrace/14646
>> > PR gdb/14647
>> > * i386-tdep.h (gdbarch_tdep): Remove sp_regnum_from_eax and
>> > pc_regnum_from_eax.
>> > * i386-tdep.c (i386_gdbarch_init): Don't use sp_regnum_from_eax
>> > nor pc_regnum_from_eax.
>> > * amd64-tdep.c (amd64_x32_init_abi): Don't set sp_regnum_from_eax
>> > nor pc_regnum_from_eax.
>> >
>
> There's got to be a better way to handle that. Did you look into
> using dwarf2_frame_set_init_reg() to establish mappings to the "raw"
> rip and rsp registers?
It doesn't work for x32 since gdbarch_sp_regnum and
gdbarch_pc_regnum are used like:
if (get_frame_func_if_available (this_frame, &entry_pc))
{
/* Decode the insns in the FDE up to the entry PC. */
instr = execute_cfa_program (fde, fde->instructions, fde->end, gdbarch,
entry_pc, fs);
if (fs->regs.cfa_how == CFA_REG_OFFSET
&& (gdbarch_dwarf2_reg_to_regnum (gdbarch, fs->regs.cfa_reg)
== gdbarch_sp_regnum (gdbarch)))
{
entry_cfa_sp_offset = fs->regs.cfa_offset;
entry_cfa_sp_offset_p = 1;
}
}
gdbarch_sp_regnum will return the wrong register number. If there are
gdbarch_frame_sp_regnum and gdbarch_frame_pc_regnum, which
default to gdbarch_sp_regnum and gdbarch_pc_regnum, respectively,
and use them everywhere, except for "p $pc/$sp", x32 can set up proper
gdbarch_frame_sp_regnum and gdbarch_frame_pc_regnum.
--
H.J.
next prev parent reply other threads:[~2012-10-03 15:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 15:26 H.J. Lu
2012-10-03 15:43 ` Mark Kettenis
2012-10-03 15:59 ` H.J. Lu [this message]
2012-10-03 17:03 ` H.J. Lu
2012-10-05 2:08 ` H.J. Lu
[not found] ` <20121003154712.GH3028@adacore.com>
[not found] ` <CAMe9rOreX6NAf08vD8=k4LBGevvTFUd-tqwwWmbsA3iRxxsE2A@mail.gmail.com>
[not found] ` <201210040657.q946vJlc006566@glazunov.sibelius.xs4all.nl>
[not found] ` <CAMe9rOounZ9e14QeMLvXR64gG5rJxQ9nNxt64YoLW54bx5VtHw@mail.gmail.com>
2012-10-08 19:48 ` Mark Kettenis
2012-10-08 20:04 ` H.J. Lu
2012-10-08 20:22 ` Mark Kettenis
2012-10-08 20:38 ` H.J. Lu
2012-10-08 20:47 ` Mark Kettenis
2012-10-08 21:01 ` H.J. Lu
2012-10-09 15:32 ` H.J. Lu
2012-10-09 15:40 ` Mark Kettenis
2012-10-09 15:48 ` Mark Kettenis
2012-10-09 16:35 ` H.J. Lu
2012-10-09 16:38 ` H.J. Lu
2012-10-15 10:10 ` Mark Kettenis
2012-10-15 20:41 ` H.J. Lu
2012-10-11 22:34 ` H.J. Lu
2012-10-12 8:31 ` Mark Kettenis
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='CAMe9rOo9Pdc=2y_1bmJ4ER-K2r-trS2SD+W7QsWbT-8KGDr4hw@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/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