This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA] Don't use builtin_long() when ptrdiff_t is needed in gnu-v3-abi.c


[I don't feel comfortable in merely asking comments on this patch, so
I'm asking for an approval instead...]

Several functions in gnu-v3-abi.c use the `long' type as a (poor)
approximation for `ptrdiff_t'.  It turns out that this approximation
works for many architectures due to the fact the size of these two
types are often the same.

The m16c (see m32c-tdep.c) has pointers which are 16 bits wide.  This
causes the ptrdiff_t type to also be 16 bits wide.  A `long', however,
is 32 bits wide.  Therefore, for the m16c, ptrdiff_t related offset
calculations made in gnu-v3-abi.c which are based on the size of a
`long' are incorrect.

This patch remedies this situation by using the same ptrdiff_t type
as that used in the construction of the vtable type.

Okay?

	* gnu-v3-abi.c (vtable_ptrdiff_type): New function.
	(gnuv3_decode_method_ptr, gnuv3_print_method_ptr)
	(gnuv3_method_ptr_to_value): Use a better approximation for
	`ptrdiff_t' instead of `long'.

Index: gnu-v3-abi.c
===================================================================
RCS file: /cvs/src/src/gdb/gnu-v3-abi.c,v
retrieving revision 1.45
diff -u -p -r1.45 gnu-v3-abi.c
--- gnu-v3-abi.c	11 Sep 2008 14:24:27 -0000	1.45
+++ gnu-v3-abi.c	5 Dec 2008 02:18:28 -0000
@@ -187,6 +187,16 @@ build_gdb_vtable_type (struct gdbarch *a
 }
 
 
+/* Return the ptrdiff_t type used in the vtable type.  */
+static struct type *
+vtable_ptrdiff_type (struct gdbarch *gdbarch)
+{
+  struct type *vtable_type = gdbarch_data (gdbarch, vtable_type_gdbarch_data);
+
+  /* The "offset_to_top" field has the appropriate (ptrdiff_t) type.  */
+  return TYPE_FIELD_TYPE(vtable_type, vtable_field_offset_to_top);
+}
+
 /* Return the offset from the start of the imaginary `struct
    gdb_gnu_v3_abi_vtable' object to the vtable's "address point"
    (i.e., where objects' virtual table pointers point).  */
@@ -531,7 +541,7 @@ gnuv3_decode_method_ptr (struct gdbarch 
 			 LONGEST *adjustment_p)
 {
   struct type *funcptr_type = builtin_type (gdbarch)->builtin_func_ptr;
-  struct type *offset_type = builtin_type (gdbarch)->builtin_long;
+  struct type *offset_type = vtable_ptrdiff_type (gdbarch);
   CORE_ADDR ptr_value;
   LONGEST voffset, adjustment;
   int vbit;
@@ -595,7 +605,7 @@ gnuv3_print_method_ptr (const gdb_byte *
       /* It's a virtual table offset, maybe in this class.  Search
 	 for a field with the correct vtable offset.  First convert it
 	 to an index, as used in TYPE_FN_FIELD_VOFFSET.  */
-      voffset = ptr_value / TYPE_LENGTH (builtin_type (gdbarch)->builtin_long);
+      voffset = ptr_value / TYPE_LENGTH (vtable_ptrdiff_type (gdbarch));
 
       physname = gnuv3_find_method_in (domain, voffset, adjustment);
 
@@ -722,7 +732,7 @@ gnuv3_method_ptr_to_value (struct value 
   if (vbit)
     {
       LONGEST voffset;
-      voffset = ptr_value / TYPE_LENGTH (builtin_type (gdbarch)->builtin_long);
+      voffset = ptr_value / TYPE_LENGTH (vtable_ptrdiff_type (gdbarch));
       return gnuv3_get_virtual_fn (gdbarch, value_ind (*this_p),
 				   method_type, voffset);
     }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]