[patch rfc] Add frame memory & arch methods

[patch rfc] Add frame memory & arch methods

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 342 bytes --]

Hello,

This adds per-frame memory and architecture methods.  Instead of using 
the global variablecurrent_gdbarch and the context dependant 
read_memory, architecture code can use these.  Should help future proof 
architecture code should thread/target changes start happening.

It uses them in the d10v.

I'll commit in a few days.

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 5455 bytes --]

2003-06-02  Andrew Cagney  <cagney@redhat.com>

	* frame.c (get_frame_memory_signed): New function.
	(get_frame_memory, get_frame_memory_unsigned): New function.
	(get_frame_arch): New function.
	* frame.h (get_frame_signed_memory, get_frame_arch): Declare.
	(get_frame_memory, get_frame_unsigned_memory): Declare.
	* d10v-tdep.c (d10v_frame_unwind_cache): Use
	get_frame_memory_unsigned and get_frame_arch.
	(d10v_frame_unwind_cache, saved_regs_unwinder): Ditto.

Index: d10v-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/d10v-tdep.c,v
retrieving revision 1.117
diff -u -r1.117 d10v-tdep.c
--- d10v-tdep.c	31 May 2003 14:20:31 -0000	1.117
+++ d10v-tdep.c	3 Jun 2003 00:35:16 -0000
@@ -665,6 +665,7 @@
 d10v_frame_unwind_cache (struct frame_info *next_frame,
 			 void **this_prologue_cache)
 {
+  struct gdbarch *gdbarch = get_frame_arch (next_frame);
   CORE_ADDR pc;
   ULONGEST prev_sp;
   ULONGEST this_base;
@@ -689,7 +690,7 @@
        pc > 0 && pc < frame_pc_unwind (next_frame);
        pc += 4)
     {
-      op = (unsigned long) read_memory_integer (pc, 4);
+      op = get_frame_memory_unsigned (next_frame, pc, 4);
       if ((op & 0xC0000000) == 0xC0000000)
 	{
 	  /* long instruction */
@@ -753,9 +754,10 @@
     {
       /* The SP was saved (which is very unusual), the frame base is
 	 just the PREV's frame's TOP-OF-STACK.  */
-      this_base = read_memory_unsigned_integer (info->saved_regs[D10V_SP_REGNUM], 
-						register_size (current_gdbarch,
-							       D10V_SP_REGNUM));
+      this_base
+	= get_frame_memory_unsigned (next_frame,
+				     info->saved_regs[D10V_SP_REGNUM], 
+				     register_size (gdbarch, D10V_SP_REGNUM));
       prev_sp = this_base;
     }
   else
@@ -779,9 +781,9 @@
 
   if (info->saved_regs[LR_REGNUM])
     {
-      CORE_ADDR return_pc 
-	= read_memory_unsigned_integer (info->saved_regs[LR_REGNUM], 
-					register_size (current_gdbarch, LR_REGNUM));
+      CORE_ADDR return_pc
+	= get_frame_memory_unsigned (next_frame, info->saved_regs[LR_REGNUM], 
+				     register_size (gdbarch, LR_REGNUM));
       info->return_pc = d10v_make_iaddr (return_pc);
     }
   else
@@ -873,7 +875,7 @@
 	int i;
 	fprintf_filtered (file, "  ");
 	frame_read_register (frame, a, num);
-	for (i = 0; i < register_size (current_gdbarch, a); i++)
+	for (i = 0; i < register_size (gdbarch, a); i++)
 	  {
 	    fprintf_filtered (file, "%02x", (num[i] & 0xff));
 	  }
@@ -1450,6 +1452,7 @@
 		     enum lval_type *lvalp, CORE_ADDR *addrp,
 		     int *realnump, void *bufferp)
 {
+  struct gdbarch *gdbarch = get_frame_arch (next_frame);
   if (this_saved_regs[regnum] != 0)
     {
       if (regnum == D10V_SP_REGNUM)
@@ -1461,7 +1464,7 @@
 	  *realnump = -1;
 	  if (bufferp != NULL)
 	    store_unsigned_integer (bufferp,
-				    register_size (current_gdbarch, regnum),
+				    register_size (gdbarch, regnum),
 				    this_saved_regs[regnum]);
 	}
       else
@@ -1475,8 +1478,8 @@
 	  if (bufferp != NULL)
 	    {
 	      /* Read the value in from memory.  */
-	      read_memory (this_saved_regs[regnum], bufferp,
-			   register_size (current_gdbarch, regnum));
+	      get_frame_memory (next_frame, this_saved_regs[regnum], bufferp,
+				register_size (gdbarch, regnum));
 	    }
 	}
       return;
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.116
diff -u -r1.116 frame.c
--- frame.c	22 May 2003 18:37:05 -0000	1.116
+++ frame.c	3 Jun 2003 00:35:21 -0000
@@ -2219,6 +2219,37 @@
   return frame;
 }
 
+/* Memory access methods.  */
+
+void
+get_frame_memory (struct frame_info *this_frame, CORE_ADDR addr, void *buf,
+		  int len)
+{
+  read_memory (addr, buf, len);
+}
+
+LONGEST
+get_frame_memory_signed (struct frame_info *this_frame, CORE_ADDR addr,
+			 int len)
+{
+  return read_memory_integer (addr, len);
+}
+
+ULONGEST
+get_frame_memory_unsigned (struct frame_info *this_frame, CORE_ADDR addr,
+			   int len)
+{
+  return read_memory_unsigned_integer (addr, len);
+}
+
+/* Architecture method.  */
+
+struct gdbarch *
+get_frame_arch (struct frame_info *this_frame)
+{
+  return current_gdbarch;
+}
+
 int
 legacy_frame_p (struct gdbarch *current_gdbarch)
 {
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.95
diff -u -r1.95 frame.h
--- frame.h	12 May 2003 00:26:18 -0000	1.95
+++ frame.h	3 Jun 2003 00:35:24 -0000
@@ -343,6 +343,25 @@
    of the caller.  */
 extern void frame_pop (struct frame_info *frame);
 
+/* Return memory from the specified frame.  A frame knows its thread /
+   LWP and hence can find its way down to a target.  The assumption
+   here is that the current and previous frame share a common address
+   space.
+
+   If the memory read fails, these methods throw an error.  */
+
+extern void get_frame_memory (struct frame_info *this_frame, CORE_ADDR addr,
+			      void *buf, int len);
+extern LONGEST get_frame_memory_signed (struct frame_info *this_frame,
+					CORE_ADDR memaddr, int len);
+extern ULONGEST get_frame_memory_unsigned (struct frame_info *this_frame,
+					   CORE_ADDR memaddr, int len);
+
+/* Return this frame's architecture.  */
+
+extern struct gdbarch *get_frame_arch (struct frame_info *this_frame);
+
+
 /* Values for the source flag to be used in print_frame_info_base(). */
 enum print_what
   { 

Re: [patch rfc] Add frame memory & arch methods

[Daniel Jacobowitz]

On Mon, Jun 02, 2003 at 08:59:45PM -0400, Andrew Cagney wrote:
> Hello,
> 
> This adds per-frame memory and architecture methods.  Instead of using 
> the global variablecurrent_gdbarch and the context dependant 
> read_memory, architecture code can use these.  Should help future proof 
> architecture code should thread/target changes start happening.
> 
> It uses them in the d10v.
> 
> I'll commit in a few days.

Could you explain to us where you see this going?  Right now it looks
like a solution without a problem.  Sure, someday they may need a
target parameter, but until we're closer to that day I don't see why a
frame parameter is the way to go.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfc] Add frame memory & arch methods

[Andrew Cagney]

> On Mon, Jun 02, 2003 at 08:59:45PM -0400, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> This adds per-frame memory and architecture methods.  Instead of using 
>> the global variablecurrent_gdbarch and the context dependant 
>> read_memory, architecture code can use these.  Should help future proof 
>> architecture code should thread/target changes start happening.
>> 
>> It uses them in the d10v.
>> 
>> I'll commit in a few days.
> 
> 
> Could you explain to us where you see this going?  Right now it looks
> like a solution without a problem.  Sure, someday they may need a
> target parameter, but until we're closer to that day I don't see why a
> frame parameter is the way to go.

Ref: [multi-arch] The frame as the global parameter (long, important),
http://sources.redhat.com/ml/gdb/2001-02/msg00335.html

Andrew

Re: [patch rfc] Add frame memory & arch methods

[Daniel Jacobowitz]

On Mon, Jun 02, 2003 at 10:33:29PM -0400, Andrew Cagney wrote:
> >On Mon, Jun 02, 2003 at 08:59:45PM -0400, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>This adds per-frame memory and architecture methods.  Instead of using 
> >>the global variablecurrent_gdbarch and the context dependant 
> >>read_memory, architecture code can use these.  Should help future proof 
> >>architecture code should thread/target changes start happening.
> >>
> >>It uses them in the d10v.
> >>
> >>I'll commit in a few days.
> >
> >
> >Could you explain to us where you see this going?  Right now it looks
> >like a solution without a problem.  Sure, someday they may need a
> >target parameter, but until we're closer to that day I don't see why a
> >frame parameter is the way to go.
> 
> Ref: [multi-arch] The frame as the global parameter (long, important),
> http://sources.redhat.com/ml/gdb/2001-02/msg00335.html

Very enlightening, thank you!

[To paraphrase you, it sure must be gratifying to see how much of that
message looks "obvious" now, two years later.]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch rfc] Add frame memory & arch methods

[Andrew Cagney]

> On Mon, Jun 02, 2003 at 10:33:29PM -0400, Andrew Cagney wrote:
> 
>> >On Mon, Jun 02, 2003 at 08:59:45PM -0400, Andrew Cagney wrote:
>> >
> 
>> >>Hello,
>> >>
>> >>This adds per-frame memory and architecture methods.  Instead of using 
>> >>the global variablecurrent_gdbarch and the context dependant 
>> >>read_memory, architecture code can use these.  Should help future proof 
>> >>architecture code should thread/target changes start happening.
>> >>
>> >>It uses them in the d10v.
>> >>
>> >>I'll commit in a few days.
> 
>> >
>> >
>> >Could you explain to us where you see this going?  Right now it looks
>> >like a solution without a problem.  Sure, someday they may need a
>> >target parameter, but until we're closer to that day I don't see why a
>> >frame parameter is the way to go.
> 
>> 
>> Ref: [multi-arch] The frame as the global parameter (long, important),
>> http://sources.redhat.com/ml/gdb/2001-02/msg00335.html
> 
> 
> Very enlightening, thank you!
> 
> [To paraphrase you, it sure must be gratifying to see how much of that
> message looks "obvious" now, two years later.]

BTW, some more recent references:

Ref: cooked regcache -> frame
http://sources.redhat.com/ml/gdb/2003-05/msg00287.html

Ref: Deprecate read_memory, write_memory
http://sources.redhat.com/ml/gdb/2003-05/msg00341.html

I've checked this in.

Andrew