From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13641 invoked by alias); 2 Mar 2011 15:57:11 -0000 Received: (qmail 13629 invoked by uid 22791); 2 Mar 2011 15:57:10 -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; Wed, 02 Mar 2011 15:56:59 +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 p22FuvhU015875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Mar 2011 10:56:57 -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 p22FutuR001472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 10:56:57 -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 p22Futmf027972; Wed, 2 Mar 2011 16:56:55 +0100 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id p22FusPB027971; Wed, 2 Mar 2011 16:56:54 +0100 Date: Wed, 02 Mar 2011 15:57:00 -0000 From: Jan Kratochvil To: Mathew Yeates Cc: Tom Tromey , gdb@sourceware.org Subject: Re: fortran multidimensional arrays and pointers Message-ID: <20110302155654.GA21742@host1.dyn.jankratochvil.net> References: <20110207193807.GA20569@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/msg00021.txt.bz2 On Thu, 24 Feb 2011 20:32:51 +0100, Mathew Yeates wrote: > Okay. I'll bite. Why is this not yet merged in FSF GDB? That is why archer-jankratochvil-vla is not merged. I have other bugs and other branches much easier to merge and they are also not merged. While I understand it is better for all the sides to merge them these branches currently live in Fedora (and Archer) and if anyone needs the functionality it is Freely available so I find other serious bugs as a more urgent problem myself. Specifically from http://sourceware.org/gdb/wiki/ArcherBranchManagement: archer-jankratochvil-ifunc: This should get merged soon / these days, I hope still for gdb-7.3. archer-jankratochvil-watchpoint3: Upon Pedro's reply http://sourceware.org/ml/gdb-patches/2010-12/msg00348.html http://sourceware.org/ml/gdb-patches/2011-01/msg00561.html I find it now waiting on some merge of linux-nat and gdbserver code which seems to be continually being worked on by Yao Qi. As I have other work to do I find it OK to just delay the merge after it. There are other patches which are very small compared to VLA and which I would also like to also merge, which suggest me they could be merged before VLA. Some of them fix linux-nat which should be soon superseded by some form of remote stub (gdbserver or ugdb or etc.). Which makes them a bit useless after the switch but currently gdbserver is not a full replacement for linux-nat. It is all related to the Yao's merges mentioned above. [patch 3/4]#3 linux-nat: Do not respawn signals http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html [patch] Fix syscall restarts for amd64->i386 biarch http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html [patch] Fix hang on the thread leader exit http://sourceware.org/ml/gdb-patches/2007-07/msg00136.html SIGSTOP which need first an upstream kernel support discussed now on lkml. various other archer-jankratochvil-vla: The patches exist since Mar 2008, currently I believe most of the code should be rewritten rather than merged. There was an unsuccessful attempt to merge it early and I later gave up on its merge and developed it rather maintainable standalone. Currently it became no longer meaningfully extensible as such non-integrated add-on patches. Currently the dynamic types to static types are converted during check_typedef. I believe check_typedef should be removed. For storing dynamic variables into convenience variables $foo there should just be stored all the parts of memory needed to evaluate the dynamic bounds into `struct value' (that is to support discontiguous value->contents). In early VLA patchset versions the macros accessing struct main_type evaluated the values dynamically. With check_typedef the GDB code is known to sometimes forget to call it. Moreover with dynamic types sometimes one wants to call it only for a single "type layer" (and no longer for its TYPE_TARGET_TYPE), in other cases one wants to call it for the type and all its subtypes. There were patches for type reference counting / garbage collecting - those were needed for the check_typedef dynamic->static variant. The types life cycle management should not be needed for VLAs with dynamic check_typedef. As with VLA even TYPE_HIGH_BOUND and other fields of main_type get runtime modified no longer makes any distinction the struct type vs. struct main_type. Therefore they should be merged. struct type was separate so that it could be modified as there was a limited number of its variants and so it does not matter they can never be freed. With proper life cycle managemement there can be single struct type/main_type. struct value needs to be simplified. At least for lval_memory the fields like OFFSET, ENCLOSING_TYPE, EMBEDDED_OFFSET and POINTED_TO_OFFSET cannot be used as the memory accessed by the type is no longer contiguous anyway (value address is a pointer to the descriptor where are contained the type's boundaries and also pointer to the real data). There should be provided some sharing of value->contents to make the code for dereferencing each dimension simple and bug-free. Fetching of the discontiguous content can be made more by virtual methods with in-GDB cache, where record_latest_value will fetch everything. I wrote it just off the top of my head now without any patches but sure some comments are welcome. Thanks, Jan