From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15769 invoked by alias); 28 Sep 2007 17:46:35 -0000 Received: (qmail 15757 invoked by uid 22791); 28 Sep 2007 17:46:34 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Sep 2007 17:46:30 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1IbJv0-0007OI-00; Fri, 28 Sep 2007 18:46:26 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IbJut-0004jm-00; Fri, 28 Sep 2007 18:46:19 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IbJut-0002SU-EA; Fri, 28 Sep 2007 18:46:19 +0100 Date: Fri, 28 Sep 2007 17:46:00 -0000 From: "Maciej W. Rozycki" To: gdb-patches@sourceware.org cc: Chris Dearman , "Maciej W. Rozycki" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Subject: mips-tdep.c: Fix retrieval of the virtual frame pointer 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-09/txt/msg00420.txt.bz2 Hello, A number of test cases in the gdb.trace/ subset fail with an error like this: (gdb) actions Enter actions for tracepoint 1, one per line. End with a line saying just "end". > collect parm[0], parm[1], parm[2], parm[3] /n/bank/raid/macro/src7-mdi/combined/gdb/arch-utils.c:200: internal-error: No virtual frame pointer available A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.trace/packetlen.exp: setup collect actions FAIL: gdb.trace/packetlen.exp: survive the long packet send (GDB internal error) The reason seems to be legacy_virtual_frame_pointer() assuming the raw and cooked numbers for the frame pointer register are the same. This is not the case for MIPS. Tested using the mipsisa32-sde-elf target, with the mips-sim-sde32/-EB and mips-sim-sde32/-EL boards, fixing 19 regressions. 2007-09-28 Chris Dearman Maciej W. Rozycki * mips-tdep.c (mips_virtual_frame_pointer): New function. (mips_gdbarch_init): Set virtual_frame_pointer function. OK to apply? Maciej 12593.diff Index: binutils-quilt/src/gdb/mips-tdep.c =================================================================== --- binutils-quilt.orig/src/gdb/mips-tdep.c 2007-09-28 16:07:41.000000000 +0100 +++ binutils-quilt/src/gdb/mips-tdep.c 2007-09-28 18:26:52.000000000 +0100 @@ -5006,6 +5006,25 @@ return value_of_register (*reg_p, frame); } +/* The default legacy_virtual_frame_pointer function checks register + numbers against gdbarch_num_regs which doesn't work for us... */ + +static void +mips_virtual_frame_pointer (CORE_ADDR pc, + int *frame_regnum, LONGEST *frame_offset) +{ + if (gdbarch_deprecated_fp_regnum (current_gdbarch) >= 0) + *frame_regnum = gdbarch_deprecated_fp_regnum (current_gdbarch); + else if (MIPS_SP_REGNUM >= 0) + *frame_regnum = MIPS_SP_REGNUM; + else + /* Should this be an internal error? I guess so, it is reflecting + an architectural limitation in the current design. */ + internal_error (__FILE__, __LINE__, + _("No virtual frame pointer available")); + *frame_offset = 0; +} + static struct gdbarch * mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) { @@ -5353,6 +5372,8 @@ set_gdbarch_elf_make_msymbol_special (gdbarch, mips_elf_make_msymbol_special); + set_gdbarch_virtual_frame_pointer (gdbarch, mips_virtual_frame_pointer); + /* Fill in the OS dependant register numbers and names. */ { const char **reg_names;