From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5675 invoked by alias); 2 Oct 2007 15:17:06 -0000 Received: (qmail 5647 invoked by uid 22791); 2 Oct 2007 15:17:04 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Oct 2007 15:16:55 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id D798098152 for ; Tue, 2 Oct 2007 15:16:53 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id BC2319810B for ; Tue, 2 Oct 2007 15:16:53 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IcjUT-0006E7-1T for gdb-patches@sourceware.org; Tue, 02 Oct 2007 11:16:53 -0400 Date: Tue, 02 Oct 2007 15:17:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: [commit] MIPS virtual frame pointer, info float Message-ID: <20071002151652.GA23302@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00014.txt.bz2 I have committed this patch after testing on mipsel-linux. It fixes two problems; the gdb.trace failures that Maciej reported last week, and obviously wrong output from "info float": f0: 0xffffffff flt: nan f1: 0xffffffff flt: nan dbl: nan We were checking the difference between the current register and the saved f0 regnum. But there's an extra NUM_REGS involved, so if NUM_REGS happens to be odd.... -- Daniel Jacobowitz CodeSourcery 2007-10-02 Daniel Jacobowitz * mips-tdep.c (mips_read_fp_register_double): Correct check for odd FP registers. (mips_print_fp_register): Correct check for even FP registers. (mips_virtual_frame_pointer): New function. (mips_gdbarch_init): Call set_gdbarch_virtual_frame_pointer. Index: gdb/mips-tdep.c =================================================================== --- gdb/mips-tdep.c (revision 182501) +++ gdb/mips-tdep.c (working copy) @@ -4006,7 +4006,9 @@ mips_read_fp_register_double (struct fra } else { - if ((regno - mips_regnum (current_gdbarch)->fp0) & 1) + int rawnum = regno % gdbarch_num_regs (current_gdbarch); + + if ((rawnum - mips_regnum (current_gdbarch)->fp0) & 1) internal_error (__FILE__, __LINE__, _("mips_read_fp_register_double: bad access to " "odd-numbered FP register")); @@ -4060,7 +4062,7 @@ mips_print_fp_register (struct ui_file * else fprintf_filtered (file, "%-17.9g", flt1); - if (regnum % 2 == 0) + if ((regnum - gdbarch_num_regs (current_gdbarch)) % 2 == 0) { mips_read_fp_register_double (frame, regnum, raw_buffer); doub = unpack_double (mips_double_register_type (), raw_buffer, @@ -4785,6 +4787,18 @@ mips_integer_to_address (struct gdbarch return (CORE_ADDR) extract_signed_integer (buf, TYPE_LENGTH (type)); } +/* Dummy virtual frame pointer method. This is no more or less accurate + than most other architectures; we just need to be explicit about it, + because the pseudo-register gdbarch_sp_regnum will otherwise lead to + an assertion failure. */ + +static void +mips_virtual_frame_pointer (CORE_ADDR pc, int *reg, LONGEST *offset) +{ + *reg = MIPS_SP_REGNUM; + *offset = 0; +} + static void mips_find_abi_section (bfd *abfd, asection *sect, void *obj) { @@ -5280,6 +5294,7 @@ mips_gdbarch_init (struct gdbarch_info i set_gdbarch_num_regs (gdbarch, num_regs); set_gdbarch_num_pseudo_regs (gdbarch, num_regs); set_gdbarch_register_name (gdbarch, mips_register_name); + set_gdbarch_virtual_frame_pointer (gdbarch, mips_virtual_frame_pointer); tdep->mips_processor_reg_names = reg_names; tdep->regnum = regnum; }