From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90062 invoked by alias); 5 Jul 2016 15:51:47 -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 90053 invoked by uid 89); 5 Jul 2016 15:51:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1050 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, 05 Jul 2016 15:51:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 90F591169F5; Tue, 5 Jul 2016 11:51:44 -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 RW19fk86kWbc; Tue, 5 Jul 2016 11:51:44 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D486D1169F7; Tue, 5 Jul 2016 11:51:43 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 54011428F4; Tue, 5 Jul 2016 08:51:42 -0700 (PDT) Date: Tue, 05 Jul 2016 15:51:00 -0000 From: Joel Brobecker To: Bernhard Heckel Cc: qiyaoltc@gmail.com, eliz@gnu.org, gdb-patches@sourceware.org Subject: Re: [PATCH V2 3/5] Fortran: Resolve dynamic target types of pointers. Message-ID: <20160705155142.GI3295@adacore.com> References: <1467625943-21294-1-git-send-email-bernhard.heckel@intel.com> <1467625943-21294-4-git-send-email-bernhard.heckel@intel.com> <20160705143544.GG3295@adacore.com> <577BD2C1.5050409@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577BD2C1.5050409@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-07/txt/msg00074.txt.bz2 > we could resolve the target when we actually access it -> value_ind. > As far as I know there is one corner case, when we print the address > and the target type has an DATA_LOCATION attribute. But I don't find > the code at the moment. > > Nevertheless, with your input it is becomes questionable if we should > resolve structures and references. > Fields of structures could be resolved when we access them -> > value_struct_elt. What do you think? For structures, I think we resolve its elements so we can know the structure's size. There is a huge comment in ada-lang.c about type 'fixing', which is hacky-before-go-lucky-dynamic-type-handling was introduced in GDB. It explains in fairly good detail when we do the resolution (we called it "fixing"), and why we do it at that time. With the new infrastructure, we could possibly do more resolution lazily, but I would focus on that later if it turns out that the only benefit of that is performance improvement. -- Joel