Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* mips-tdep.c: Fix retrieval of the virtual frame pointer
@ 2007-09-28 17:46 Maciej W. Rozycki
  2007-09-28 17:57 ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Maciej W. Rozycki @ 2007-09-28 17:46 UTC (permalink / raw)
  To: gdb-patches; +Cc: Chris Dearman, Maciej W. Rozycki

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  <chris@mips.com>
            Maciej W. Rozycki  <macro@mips.com>

	* 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;


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mips-tdep.c: Fix retrieval of the virtual frame pointer
  2007-09-28 17:46 mips-tdep.c: Fix retrieval of the virtual frame pointer Maciej W. Rozycki
@ 2007-09-28 17:57 ` Daniel Jacobowitz
  2007-09-28 18:14   ` Maciej W. Rozycki
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2007-09-28 17:57 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: gdb-patches, Chris Dearman, Maciej W. Rozycki

On Fri, Sep 28, 2007 at 06:46:19PM +0100, Maciej W. Rozycki wrote:
> Hello,
> 
>  A number of test cases in the gdb.trace/ subset fail with an error like 
> this:

Have I mentioned that I have queued patches I haven't gotten to yet?
:-)  I spent the past two weeks fighting with an obstinate qemu, and
one of the patches I was testing was basically this one.

Mine was:

+/* 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;
+}

I think this is more accurate than yours, since these:

> +  if (gdbarch_deprecated_fp_regnum (current_gdbarch) >= 0)

> +  else if (MIPS_SP_REGNUM >= 0)

are both constants for MIPS.

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mips-tdep.c: Fix retrieval of the virtual frame pointer
  2007-09-28 17:57 ` Daniel Jacobowitz
@ 2007-09-28 18:14   ` Maciej W. Rozycki
  2007-09-28 18:19     ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Maciej W. Rozycki @ 2007-09-28 18:14 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb-patches, Chris Dearman, Maciej W. Rozycki

On Fri, 28 Sep 2007, Daniel Jacobowitz wrote:

> Have I mentioned that I have queued patches I haven't gotten to yet?
> :-)  I spent the past two weeks fighting with an obstinate qemu, and
> one of the patches I was testing was basically this one.

 I see...

> Mine was:
> 
> +/* 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;
> +}
> 
> I think this is more accurate than yours, since these:

 You mean simpler?  No argument.

> > +  if (gdbarch_deprecated_fp_regnum (current_gdbarch) >= 0)
> 
> > +  else if (MIPS_SP_REGNUM >= 0)
> 
> are both constants for MIPS.

 Well, this may change in theory, but I know of no plans to do that, so 
shall I replace Chris's patch with yours and test it and you will commit 
it shortly?

  Maciej


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mips-tdep.c: Fix retrieval of the virtual frame pointer
  2007-09-28 18:14   ` Maciej W. Rozycki
@ 2007-09-28 18:19     ` Daniel Jacobowitz
  2007-10-01 11:27       ` Maciej W. Rozycki
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2007-09-28 18:19 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: gdb-patches, Chris Dearman, Maciej W. Rozycki

On Fri, Sep 28, 2007 at 07:13:47PM +0100, Maciej W. Rozycki wrote:
>  Well, this may change in theory, but I know of no plans to do that, so 
> shall I replace Chris's patch with yours and test it and you will commit 
> it shortly?

I've just successfully finished testing it; a related patch is
halfway through a test cycle now.  I'll plan to commit it Monday,
OK?

-- 
Daniel Jacobowitz
CodeSourcery


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: mips-tdep.c: Fix retrieval of the virtual frame pointer
  2007-09-28 18:19     ` Daniel Jacobowitz
@ 2007-10-01 11:27       ` Maciej W. Rozycki
  0 siblings, 0 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2007-10-01 11:27 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb-patches, Chris Dearman, Maciej W. Rozycki

On Fri, 28 Sep 2007, Daniel Jacobowitz wrote:

> I've just successfully finished testing it; a related patch is
> halfway through a test cycle now.  I'll plan to commit it Monday,
> OK?

 Fine with me, thanks.

  Maciej


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-10-01 11:27 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-28 17:46 mips-tdep.c: Fix retrieval of the virtual frame pointer Maciej W. Rozycki
2007-09-28 17:57 ` Daniel Jacobowitz
2007-09-28 18:14   ` Maciej W. Rozycki
2007-09-28 18:19     ` Daniel Jacobowitz
2007-10-01 11:27       ` Maciej W. Rozycki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox