* DWARF register numbering discrepancy on SPARC between GCC and GDB
@ 2009-01-21 11:09 Joel Brobecker
2009-01-21 12:00 ` Rainer Orth
2009-01-21 12:37 ` Mark Kettenis
0 siblings, 2 replies; 6+ messages in thread
From: Joel Brobecker @ 2009-01-21 11:09 UTC (permalink / raw)
To: gcc, gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
2009-01-21 11:09 DWARF register numbering discrepancy on SPARC between GCC and GDB Joel Brobecker
@ 2009-01-21 12:00 ` Rainer Orth
2009-01-21 12:37 ` Mark Kettenis
1 sibling, 0 replies; 6+ messages in thread
From: Rainer Orth @ 2009-01-21 12:00 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gcc, gdb
Joel Brobecker <brobecker@adacore.com> writes:
> 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?
I'd suggest asking on tools-compilers@opensolaris.org where several Sun
compiler developers hang around. An alternative is the Sun Studio Tools
Forums at
http://forums.sun.com/forum.jspa?forumID=852
although I find that forum stuff inconvenient to use compared to true
mailing lists.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
2009-01-21 11:09 DWARF register numbering discrepancy on SPARC between GCC and GDB Joel Brobecker
2009-01-21 12:00 ` Rainer Orth
@ 2009-01-21 12:37 ` Mark Kettenis
2009-01-21 14:22 ` Eric Botcazou
1 sibling, 1 reply; 6+ messages in thread
From: Mark Kettenis @ 2009-01-21 12:37 UTC (permalink / raw)
To: brobecker, ebotcazou; +Cc: gcc, gdb
> Date: Wed, 21 Jan 2009 15:08:47 +0400
>
> 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.
Strange, since the GCC 3.2 installed on one of the Solaris boxes at
work defenitely starts numbering from 32.
> 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.
Ah, but he is overlooking that sol2.h used to have its own defenition
of DBX_REGISTER_NUMBER:
/* However it appears that Solaris 2.0 uses the same reg numbering as
the old BSD-style system did. */
/* Same as sparc.h */
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(REGNO) \
(TARGET_FLAT && (REGNO) == HARD_FRAME_POINTER_REGNUM ? 31 : REGNO)
> 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?
Obviously the GCC folks broke backwards compatibility with themselves.
So unless we find evidence that contradicts the wiki page you cite, I
think GCC needs to be fixed.
OpenBSD and Linux are fine; they use 32-63 to number f0-f31.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
2009-01-21 12:37 ` Mark Kettenis
@ 2009-01-21 14:22 ` Eric Botcazou
2009-01-21 20:14 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Eric Botcazou @ 2009-01-21 14:22 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gcc, brobecker, gdb
> Obviously the GCC folks broke backwards compatibility with themselves.
> So unless we find evidence that contradicts the wiki page you cite, I
> think GCC needs to be fixed.
Yes, the SVR4 definition used to be masked by that of the sol2.h file on
Solaris and is not anymore. But the SVR4 definition is the one used for
the various BSD variants.
> OpenBSD and Linux are fine; they use 32-63 to number f0-f31.
Linux is fine, OpenBSD is not, at least in the FSF tree.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
2009-01-21 14:22 ` Eric Botcazou
@ 2009-01-21 20:14 ` David Miller
2009-01-22 11:51 ` Eric Botcazou
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2009-01-21 20:14 UTC (permalink / raw)
To: ebotcazou; +Cc: mark.kettenis, gcc, brobecker, gdb
From: Eric Botcazou <ebotcazou@adacore.com>
Date: Wed, 21 Jan 2009 15:22:19 +0100
> > Obviously the GCC folks broke backwards compatibility with themselves.
> > So unless we find evidence that contradicts the wiki page you cite, I
> > think GCC needs to be fixed.
>
> Yes, the SVR4 definition used to be masked by that of the sol2.h file on
> Solaris and is not anymore. But the SVR4 definition is the one used for
> the various BSD variants.
Ok, so it seems the fix is to reinstate the override in sol2.h,
right?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
2009-01-21 20:14 ` David Miller
@ 2009-01-22 11:51 ` Eric Botcazou
0 siblings, 0 replies; 6+ messages in thread
From: Eric Botcazou @ 2009-01-22 11:51 UTC (permalink / raw)
To: David Miller; +Cc: gcc, mark.kettenis, brobecker, gdb
> Ok, so it seems the fix is to reinstate the override in sol2.h,
> right?
This wouldn't change anything except for Solaris. The fix is probably to wipe
out the SVR4 definition (and consequently all definitions in config/sparc
since the remaining ones will duplicate the default).
--
Eric Botcazou
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-01-22 11:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-21 11:09 DWARF register numbering discrepancy on SPARC between GCC and GDB Joel Brobecker
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox