From: Joel Brobecker <brobecker@adacore.com>
To: gcc@gcc.gnu.org, gdb@sourceware.org
Subject: DWARF register numbering discrepancy on SPARC between GCC and GDB
Date: Wed, 21 Jan 2009 11:09:00 -0000 [thread overview]
Message-ID: <20090121110847.GU5709@adacore.com> (raw)
Hello,
Eric and I discovered a discrepancy in the DWARF register numbering
on SPARC for floating point registers. The problem is more visible
on SPARC 64-bit because they are used for parameter passing, whether
i0 is used on 32-bit SPARC. Consider for instance the following code:
volatile register float r asm("f0");
int foo(float f)
{
r = f;
}
At -O0 -g:
st %i0, [%fp+68]
ld [%fp+68], %f0
.byte 0x5 ! uleb128 0x5; (DIE (0xd2) DW_TAG_variable)
.ascii "r\0" ! DW_AT_name
.byte 0x1 ! DW_AT_decl_file (t.c)
.byte 0x1 ! DW_AT_decl_line
.uaword 0xdf ! DW_AT_type
.byte 0x1 ! DW_AT_external
.byte 0x2 ! DW_AT_location
.byte 0x90 ! DW_OP_regx
!!-> .byte 0x28 ! uleb128 0x28
.byte 0x6 ! uleb128 0x6; (DIE (0xdf) DW_TAG_volatile_type)
.uaword 0xc9 ! DW_AT_type
As you can see, GCC tells us that variable "r" is in register 0x28=40.
The problem is that GCC thinks that register 40 is f0, whereas GDB
thinks that register 32 is f0.
More generally, GCC thinks that registers f0-f31 should be numbered 40-71:
/* Define how the SPARC registers should be numbered for Dwarf output.
The numbering provided here should be compatible with the native
svr4 SDB debugger in the SPARC/svr4 reference port. The numbering
is as follows:
Assembly name gcc internal regno Dwarf regno
----------------------------------------------------------
g0-g7 0-7 0-7
o0-o7 8-15 8-15
l0-l7 16-23 16-23
i0-i7 24-31 24-31
f0-f31 32-63 40-71
According to Eric, this has been like that for the past since 1992.
However, when I tried to find some kind of official document
to confirm this numbering, I only found:
http://wikis.sun.com/display/SunStudio/Dwarf+Register+Numbering
This is a wiki page, so I'm not sure how much we can trust the contents.
However, it does contradict the numbers above: Apparently DBX expects
f0-f31 to be numbered 32-63, not 40-71. If that information is correct,
perhaps Sun changed it since the first implementation in SDB? Does
anyone have maybe a more affirmative document?
The decision we need to make is to decide whether to change GDB
to match GCC or to change GCC. Changing GDB shouldn't be very hard,
but I think we should choose the same numbering scheme as DBX.
Opinions?
Thank you!
--
Joel
next reply other threads:[~2009-01-21 11:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 11:09 Joel Brobecker [this message]
2009-01-21 12:00 ` Rainer Orth
2009-01-21 12:37 ` Mark Kettenis
2009-01-21 14:22 ` Eric Botcazou
2009-01-21 20:14 ` David Miller
2009-01-22 11:51 ` Eric Botcazou
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=20090121110847.GU5709@adacore.com \
--to=brobecker@adacore.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
/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