From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20013 invoked by alias); 26 Nov 2005 16:52:44 -0000 Received: (qmail 20006 invoked by uid 22791); 26 Nov 2005 16:52:44 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Nov 2005 16:52:42 +0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9) with ESMTP id jAQGqYqO023341; Sat, 26 Nov 2005 11:52:35 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id jAQGqY9Y023338; Sat, 26 Nov 2005 11:52:34 -0500 (EST) Message-Id: <200511261652.jAQGqY9Y023338@hiauly1.hia.nrc.ca> Subject: Re: Register numbers on hppa64 To: randolph@tausq.org (Randolph Chung) Date: Sat, 26 Nov 2005 17:13:00 -0000 From: "John David Anglin" Cc: gdb@sources.redhat.com, brobecker@adacore.com In-Reply-To: <43880E6B.8060901@tausq.org> from "Randolph Chung" at Nov 26, 2005 03:27:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00579.txt.bz2 > OK, this is a mess....:) > > Apparently we now have at least three different register numbering > schemes for hppa64: > > 1) gcc "dbx": > 0-31: r0-r31 > 72-135: fr0-fr31 (odd numbers are not used) GCC regno 32 is fr4. fr0 through fr3 aren't known to GCC. So, we actually have: 72, 74, ...: fr4, fr5, ... This appears compatible with the gdb mapping. > 60: sar I believe that sar is 32 in the gcc dbx mapping. > 2) gcc dwarf frame: > unity mapping, so: > 0-31: r0-r31 > 32-59: fr4-fr31 > 60: sar This can't change (at least not easily). This is tied to the allocation of the dwarf_reg_size_table.s The only way this can change is by adding the control and space registers that GCC doesn't currently know about to GCC's register tables. This will impact performance to some extent. There's also no easy way to use these registers as they are mostly priviledged or require special access techniques. > 3) gdb > 0-31: r0-r31 > 32-63: sar, pcoqh, pcsqh, other "special" registers > 64-95: fr0-fr31 > > 4) HP compilers > ??? This doesn't matter since HP uses a proprietary debug format. I believe that the dbx mapping generally corresponds to the ordering used by HP for fp_int_block_t, __reg32_t and __reg64_t in the save state. However, the introduction of PA 2.0 made the save state more complex. See the definition for struct save_state in pa/save_state.h. Thus, numbering compatibility with the save state probably isn't as useful as it once once. > The gdb numbering scheme seems to be there for a long time. I don't know > if this is the way HP numbers registers in their debug format. Does > anybody have a pointer to this information? The current gcc numbering scheme has also been there for a long time. At the moment, I don't see a reason to change the number scheme anywhere. It seems that if there is a problem, it's in gdb (dbx vs. dwarf numbers). Adding unused registers to gcc register tables isn't going to help performance and it might break exception support if code from two GCC versions is linked together. We can define DWARF_FRAME_REGISTERS if we need more frame registers (e.g., to restore the floating-point state or 64-bit registers in 32-bit mode). However, at the moment, the unwind hooks to do this aren't there. One bit in gcc bothers me. If we didn't define DWARF_FRAME_REGNUM (i.e., used the dbx default), it appears we could map the dbx numbers to frame numbers using DWARF2_FRAME_REG_OUT. The two techniques appear redundant unless we actually need to define DWARF2_FRAME_REG_OUT to map dbx numbers to frame numbers (i.e., the documentation is wrong about the numbers being collected using DWARF_FRAME_REGNUM). In the rs6000 sysv4.h case, DWARF_FRAME_REGNUM is also the gcc hard registers but it appears that the ABIs mandate numbers for .debug_frame, so a remapping is needed. In our case, we don't have an ABI... > I see that in late 2003/early 2004 there was a discussion about archs > with mismatched "dbx register numbers" vs "dwarf CFI register numbers" > on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion > was about ppc64, although i was not quite sure what was the conclusion > of those discussions. hppa64 is in a similar situation. I guess this was the result: 2004-01-21 Alan Modra * config/rs6000/sysv4.h (DWARF2_FRAME_REG_OUT): Define. * dwarf2out.c (output_cfi): Map regs using DWARF2_FRAME_REG_OUT. * doc/tm.texi (DWARF_FRAME_REGNUM, DWARF2_FRAME_REG_OUT): Document. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)