This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[RFA] Don't use builtin_long() when ptrdiff_t is needed in gnu-v3-abi.c
- From: Kevin Buettner <kevinb at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Thu, 4 Dec 2008 21:22:51 -0700
- Subject: [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);
}