From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [RFC] rl78: vtables are code addresses
Date: Tue, 11 Feb 2014 06:44:00 -0000 [thread overview]
Message-ID: <20140210234449.27faedc6@redhat.com> (raw)
This patch, for rl78 using the default multilib, fixes 5 failures in
gdb.cp/casts.exp, 2 failures in gdb.cp/class2.exp, 115 failures in
gdb.mi/mi-var-rtti.exp, and 2 failures in gdb.python/py-value.exp.
It introduces 9 failures (regressions) in gdb.mi/mi-var-rtti.exp.
One of the regressions is:
FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
The relevant lines from the log file from a pre-patch test run are as
follows:
-var-list-children S.public
^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
(gdb)
PASS: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
Expecting: ^(-var-list-children S\.public\.ptr [
]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
]+[(]gdb[)]
[ ]*)
------
The same set of lines for the failing (post-patch) run are instead:
-var-list-children S.public
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
&"warning: can't find linker symbol for virtual table for `Base' value\n"
&"warning: found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
(gdb)
FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
Expecting: ^(-var-list-children S\.public\.ptr [
]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
]+[(]gdb[)]
[ ]*)
------
Note that the difference between these are the warnings regarding
linker symbols. Aside from the warnings, the result is the same.
I.e. gdb produces the correct answer despite the warnings. The
reason for the other 8 failures is the same: the test harness is not
expecting these warnings.
I spent some time (a while ago) looking at the reason for these
warnings. As I recall, we are now getting further along in the type
resolution process than we were without my patch. I.e. for the
example above, the code in question never got to the point where it
was looking for the specified linker symbol. So it seems to me that,
at worst, my patch exposes some other problem, but is not directly
the cause of the problem.
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.
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)
+ 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))
- || TYPE_LENGTH (type) == 4)
+ || TYPE_LENGTH (type) == 4
+ || vtable)
return rl78_make_instruction_address (addr);
else
return rl78_make_data_address (addr);
next reply other threads:[~2014-02-11 6:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 6:44 Kevin Buettner [this message]
2014-02-11 9:30 ` Joel Brobecker
2014-02-11 10:42 ` Pedro Alves
2014-02-11 16:38 ` Kevin Buettner
2014-02-12 13:32 ` Pedro Alves
2014-02-12 19:42 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140210234449.27faedc6@redhat.com \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox