This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] rl78: vtables are code addresses
- From: Pedro Alves <palves at redhat dot com>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 11 Feb 2014 10:42:37 +0000
- Subject: Re: [RFC] rl78: vtables are code addresses
- Authentication-results: sourceware.org; auth=none
- References: <20140210234449 dot 27faedc6 at redhat dot com>
On 02/11/2014 06:44 AM, Kevin Buettner wrote:
> I would like to commit this patch because, on balance, it markedly
> improves the test results. Without objection(s), I'll commit this
> patch in a few days time.
>
> Kevin
>
> * rl78-tdep.c (rl78_pointer_to_address): Add logic so that
> vtables are considered to be code addresses.
Isn't this going to be needed for all Harvard targets?
Or rather, can't we always consider this to be code for
all targets?
>
> diff --git a/gdb/rl78-tdep.c b/gdb/rl78-tdep.c
> index c28db4b..d067b43 100644
> --- a/gdb/rl78-tdep.c
> +++ b/gdb/rl78-tdep.c
> @@ -764,14 +764,27 @@ rl78_pointer_to_address (struct gdbarch *gdbarch,
> struct type *type, const gdb_byte *buf)
> {
> enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> + int vtable = 0;
> CORE_ADDR addr
> = extract_unsigned_integer (buf, TYPE_LENGTH (type), byte_order);
>
> + /* See if it's a vtable. */
> + if (TYPE_CODE (type) == TYPE_CODE_PTR)
> + {
> + struct type *targ_type = TYPE_TARGET_TYPE (type);
> +
> + if (TYPE_CODE (targ_type) == TYPE_CODE_STRUCT
> + && TYPE_TAG_NAME (targ_type) != NULL
> + && strcmp (TYPE_TAG_NAME (targ_type), "gdb_gnu_v3_abi_vtable") == 0)
Hmm. gdb_gnu_v3_abi_vtable is a type baked by GDB itself.
> + vtable = 1;
> + }
> +
> /* Is it a code address? */
> if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_FUNC
> || TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_METHOD
> || TYPE_CODE_SPACE (TYPE_TARGET_TYPE (type))
and we already check that the target type is code here. But
the type system didn't know that. But, shouldn't it?
> - || TYPE_LENGTH (type) == 4)
> + || TYPE_LENGTH (type) == 4
> + || vtable)
> return rl78_make_instruction_address (addr);
> else
> return rl78_make_data_address (addr);
>
Thus, wouldn't it be a little better to mark the baked in struct
type as code to begin with?
---
gdb/gnu-v3-abi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/gnu-v3-abi.c b/gdb/gnu-v3-abi.c
index a08dc36..ceccbe5 100644
--- a/gdb/gnu-v3-abi.c
+++ b/gdb/gnu-v3-abi.c
@@ -171,7 +171,7 @@ build_gdb_vtable_type (struct gdbarch *arch)
TYPE_TAG_NAME (t) = "gdb_gnu_v3_abi_vtable";
INIT_CPLUS_SPECIFIC (t);
- return t;
+ return make_type_with_address_space (t, TYPE_INSTANCE_FLAG_CODE_SPACE);
}
I believe this makes no difference for archs with flat address space.
(testing on x86-64 GNU/Linux shows no changes).
--
1.7.11.7