From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30427 invoked by alias); 21 Jan 2009 12:37:42 -0000 Received: (qmail 30324 invoked by uid 22791); 21 Jan 2009 12:37:41 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_35 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jan 2009 12:37:39 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n0LCb3Di026688; Wed, 21 Jan 2009 13:37:03 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n0LCb2wB017368; Wed, 21 Jan 2009 13:37:02 +0100 (CET) Date: Wed, 21 Jan 2009 12:37:00 -0000 Message-Id: <200901211237.n0LCb2wB017368@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com, ebotcazou@adacore.com CC: gcc@gcc.gnu.org, gdb@sourceware.org In-reply-to: <20090121110847.GU5709@adacore.com> (message from Joel Brobecker on Wed, 21 Jan 2009 15:08:47 +0400) Subject: Re: DWARF register numbering discrepancy on SPARC between GCC and GDB References: <20090121110847.GU5709@adacore.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00140.txt.bz2 > 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.