From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29928 invoked by alias); 11 Feb 2014 06:44:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29919 invoked by uid 89); 11 Feb 2014 06:44:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Feb 2014 06:44:52 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1B6ioaa030709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Feb 2014 01:44:51 -0500 Received: from localhost.localdomain (ovpn-113-31.phx2.redhat.com [10.3.113.31]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1B6iogp025149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Feb 2014 01:44:50 -0500 Date: Tue, 11 Feb 2014 06:44:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: [RFC] rl78: vtables are code addresses Message-ID: <20140210234449.27faedc6@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00338.txt.bz2 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);