From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9351 invoked by alias); 3 Mar 2011 17:43:35 -0000 Received: (qmail 9339 invoked by uid 22791); 3 Mar 2011 17:43:33 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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:43:29 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p23HhSqQ007306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Mar 2011 12:43:28 -0500 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p23HhQgv016824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2011 12:43:27 -0500 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p23HhP22013028; Thu, 3 Mar 2011 18:43:25 +0100 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id p23HhP0q013027; Thu, 3 Mar 2011 18:43:25 +0100 Date: Thu, 03 Mar 2011 17:43:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: Mathew Yeates , gdb@sourceware.org Subject: Re: fortran multidimensional arrays and pointers Message-ID: <20110303174325.GA12680@host1.dyn.jankratochvil.net> References: <20110207193807.GA20569@host1.dyn.jankratochvil.net> <20110302155654.GA21742@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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/msg00037.txt.bz2 On Thu, 03 Mar 2011 18:23:58 +0100, Tom Tromey wrote: > 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. It is not about waiting but there may be needed some effort before they get merged and then (with gdbserver/ugdb/...) the code gets dropped anyway. > 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? check_typedef does multiple things, and more of them in the VLA branch. One of them in FSF GDB is to set TYPE_LENGTH - this could be dynamic. In other cases the code may want to access either the TYPE_CODE_TYPEDEF layer or the dereferenced one (possibly resolved from TYPE_IS_OPAQUE) etc. Sometimes the code wants to know if the boundary is dynamic sometimes it wants to know the resolved number. In general I agree but I would need to start patching the code first. BTW also most of the `struct type *' pointers need to be changed to `struct value *' as dynamic types resolving for VLA depends on the object address (DW_AT_object_pointer). There is a global variable for it in the VLA branch but a global variable is wrong by design causing various problems there. > 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. Yes, it is the right thing but completely needless. There is a need for discontiguous value->contents (such as for multidimensional array slices) and there is a need for dynamic type parameters resolution (to simplify the code by removing check_typedef). In such case there is already enough functionality one does not need to implement the conversion to static types. It remains to be an inappropriate performance optimization. > 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. We can do some benchmarks if you mean it seriously but such memory saving has no relevant size to ever consider it. > 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. Yes, this cleanup has multiple benefits. Thanks, Jan