From patchwork Tue Aug 19 13:42:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Brobecker X-Patchwork-Id: 2435 Received: (qmail 13155 invoked by alias); 19 Aug 2014 13:42:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 13145 invoked by uid 89); 19 Aug 2014 13:42:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 19 Aug 2014 13:42:22 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EBC101162D5 for ; Tue, 19 Aug 2014 09:42:20 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JHgMIt2f1UsH for ; Tue, 19 Aug 2014 09:42:20 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C0A601162D4 for ; Tue, 19 Aug 2014 09:42:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D6C92410DF; Tue, 19 Aug 2014 15:42:19 +0200 (CEST) From: Joel Brobecker To: gdb-patches@sourceware.org Subject: FYI: value_from_pointer: remove call to resolve_dynamic_type Date: Tue, 19 Aug 2014 15:42:14 +0200 Message-Id: <1408455734-8185-1-git-send-email-brobecker@adacore.com> Hello, FYI, I am about to apply the following patch to HEAD. The reason I stumbled upon it is because I was trying to see how difficult (in terms of number of changes), it would be to add some extra contextual data to the resolve_dynamic* functions. That when I noticed that value_from_pointer calls resolve_dynamic_type, and I couldn't figure out, from a logical standpoint, why that was necessary. If any resolution is actually needed, it seems to me that this resolution should be done when dereferencing the pointer, and it just so happens to be the case already. Furthermore, just operating from a pratical perspective, it turns out that the given type always being a TYPE_CODE_PTR, it should really never be dynamic, and making the call to resolve_dynamic_type an unnecessary no-op. So this patch removes this call. gdb/ChangeLog: * value.c (value_from_pointer): Remove use of resolve_dynamic_type. Adjust code accordingly. Adjust function description comment. Tested on x86_64-linux. Pushing... --- gdb/ChangeLog | 5 +++++ gdb/value.c | 9 +++------ 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 7c3c582..5d446ab 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2014-08-19 Joel Brobecker + + * value.c (value_from_pointer): Remove use of resolve_dynamic_type. + Adjust code accordingly. Adjust function description comment. + 2014-08-19 Alan Modra * acinclude.m4 (GDB_AC_CHECK_BFD): Don't add -ldl. diff --git a/gdb/value.c b/gdb/value.c index 3d460bd..cec1d4a 100644 --- a/gdb/value.c +++ b/gdb/value.c @@ -3342,18 +3342,15 @@ value_from_ulongest (struct type *type, ULONGEST num) /* Create a value representing a pointer of type TYPE to the address - ADDR. The type of the created value may differ from the passed - type TYPE. Make sure to retrieve the returned values's new type - after this call e.g. in case of an variable length array. */ + ADDR. */ struct value * value_from_pointer (struct type *type, CORE_ADDR addr) { - struct type *resolved_type = resolve_dynamic_type (type, addr); - struct value *val = allocate_value (resolved_type); + struct value *val = allocate_value (type); store_typed_address (value_contents_raw (val), - check_typedef (resolved_type), addr); + check_typedef (type), addr); return val; }