From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10540 invoked by alias); 3 Mar 2011 17:24:11 -0000 Received: (qmail 10532 invoked by uid 22791); 3 Mar 2011 17:24:09 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Mar 2011 17:24:02 +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 p23HO0HL032518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 12:24:00 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p23HNxk3008849; Thu, 3 Mar 2011 12:23:59 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p23HNwnK006291; Thu, 3 Mar 2011 12:23:59 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id B1F763785EB; Thu, 3 Mar 2011 10:23:58 -0700 (MST) From: Tom Tromey To: Jan Kratochvil Cc: Mathew Yeates , gdb@sourceware.org Subject: Re: fortran multidimensional arrays and pointers References: <20110207193807.GA20569@host1.dyn.jankratochvil.net> <20110302155654.GA21742@host1.dyn.jankratochvil.net> Date: Thu, 03 Mar 2011 17:24:00 -0000 In-Reply-To: <20110302155654.GA21742@host1.dyn.jankratochvil.net> (Jan Kratochvil's message of "Wed, 2 Mar 2011 16:56:54 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00036.txt.bz2 Jan> Some of them fix linux-nat which should be soon superseded by some Jan> form of remote stub (gdbserver or ugdb or etc.). Which makes them a Jan> bit useless after the switch but currently gdbserver is not a full Jan> replacement for linux-nat. While I think this is a good future direction, I would not delay any patch while waiting for it to be finished. Jan> archer-jankratochvil-vla: Jan> The patches exist since Mar 2008, currently I believe most of the Jan> code should be rewritten rather than merged. Ouch. Jan> Currently the dynamic types to static types are converted during Jan> check_typedef. I believe check_typedef should be removed. I guess I can see how it could be done: replace all TYPE_* macros with functions, and do the typedef indirection there. Is that what you are thinking, or do you have some other idea? Jan> For storing dynamic variables into convenience variables $foo there Jan> should just be stored all the parts of memory needed to evaluate Jan> the dynamic bounds into `struct value' (that is to support Jan> discontiguous value->contents). In early VLA patchset versions the Jan> macros accessing struct main_type evaluated the values dynamically. It seems to me that once you assign to a convenience variable, you are taking a snapshot of a particular instance of a VLA. So, converting to a statically-bounded type would be the right thing to do here. Jan> There were patches for type reference counting / garbage collecting Jan> - those were needed for the check_typedef dynamic->static variant. Jan> The types life cycle management should not be needed for VLAs with Jan> dynamic check_typedef. FWIW this work still seems relevant; you can still leak types via Python. It isn't urgent since this only happens in relatively weird scenarios. Jan> As with VLA even TYPE_HIGH_BOUND and other fields of main_type get Jan> runtime modified no longer makes any distinction the struct type Jan> vs. struct main_type. Therefore they should be merged. I am not so sure about this. Type variants also save memory. Jan> There should be provided some sharing of value->contents to make Jan> the code for dereferencing each dimension simple and bug-free. Jan> Fetching of the discontiguous content can be made more by virtual Jan> methods with in-GDB cache, where record_latest_value will fetch Jan> everything. Yeah. I think we need to destroy val_print, and only have value_print -- but keep finding tricks to avoid it since it is so much work. Once that is done, fully virtualizing struct value like this would not be so hard (famous last words), and would also let us address lazily read arrays at print time. Tom