From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26426 invoked by alias); 11 Feb 2014 10:42:42 -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 26417 invoked by uid 89); 11 Feb 2014 10:42:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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 10:42:40 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1BAgdWB010607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Feb 2014 05:42:39 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1BAgbdv026005; Tue, 11 Feb 2014 05:42:38 -0500 Message-ID: <52F9FE9D.6050603@redhat.com> Date: Tue, 11 Feb 2014 10:42:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Buettner CC: gdb-patches@sourceware.org Subject: Re: [RFC] rl78: vtables are code addresses References: <20140210234449.27faedc6@redhat.com> In-Reply-To: <20140210234449.27faedc6@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00348.txt.bz2 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