From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9991 invoked by alias); 30 Nov 2012 15:50:09 -0000 Received: (qmail 9947 invoked by uid 22791); 30 Nov 2012 15:50:06 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 30 Nov 2012 15:49:56 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAUFntd0002724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Nov 2012 10:49:55 -0500 Received: from host2.jankratochvil.net (ovpn-116-104.ams2.redhat.com [10.36.116.104]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAUFnpp3027104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Nov 2012 10:49:54 -0500 Date: Fri, 30 Nov 2012 15:50:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb@sourceware.org Subject: Re: plan: VLA (Variable Length Arrays) and Fortran dynamic types Message-ID: <20121130154951.GA8208@host2.jankratochvil.net> References: <20121129144855.GA16288@host2.jankratochvil.net> <874nk83wok.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874nk83wok.fsf@fleche.redhat.com> 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: 2012-11/txt/msg00101.txt.bz2 On Thu, 29 Nov 2012 22:51:07 +0100, Tom Tromey wrote: > Passing a struct value everywhere seems pretty awful though too, > especially considering that one may not generally have a value. > 'ptype' and plenty of other things have to work on the abstract type. There is needed 'struct value' with some dummy content in such case. It also means you cannot 'ptype' VLA type (or dynamic Fortran array), you need an inferior variable instance for VLA. I have checked now that 'ptype char[5]' works even without VLA. But that sets TYPE_LENGTH to 5 and TYPE_TARGET_STUB == 0 so check_typedef does not overwrite the value 5 (it also has no TYPE_CODE_RANGE anywhere). Dummy 'struct value' is the disadvantage of a fully dynamic solution but it is nice we share the opinion with Joel a fully dynamic solution (without concretization) should be better. I did not use you words 'abstract type' as I used 'struct abstract_type' in my text also for inferior types not yet passed through check_typedef. For non-VLA types it means 'struct abstract_type' may be opaque type. > But I think maybe I don't understand some details here. Could you give > an example of where we pass a type now that we would have to pass a > value in the future? It may also depend a bit on the behavior currently in archer-jankratochvil-vla as: (gdb) whatis temp1 type = char [variable] (gdb) ptype temp1 type = char [78] Currently it did mean how many check_typedefs to call, with fully dynamic types in GDB there will need to be different way (flag) to access the array bound value. For example LA_PRINT_TYPE parameter type -> value. I do not know more, just change type->value at any TYPE_LENGTH and similar accessors, and then change it in all the callers. Jan