Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com, ebotcazou@adacore.com
Cc: gcc@gcc.gnu.org, gdb@sourceware.org
Subject: Re: DWARF register numbering discrepancy on SPARC between GCC and GDB
Date: Wed, 21 Jan 2009 12:37:00 -0000	[thread overview]
Message-ID: <200901211237.n0LCb2wB017368@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20090121110847.GU5709@adacore.com> (message from Joel Brobecker 	on Wed, 21 Jan 2009 15:08:47 +0400)

> 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.


  parent reply	other threads:[~2009-01-21 12:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-21 11:09 Joel Brobecker
2009-01-21 12:00 ` Rainer Orth
2009-01-21 12:37 ` Mark Kettenis [this message]
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=200901211237.n0LCb2wB017368@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=brobecker@adacore.com \
    --cc=ebotcazou@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