From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118806 invoked by alias); 17 Apr 2015 15:07:36 -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 118778 invoked by uid 89); 17 Apr 2015 15:07:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 17 Apr 2015 15:07:34 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 15D712DB30D1; Fri, 17 Apr 2015 17:07:31 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMFiKDD5jEFw; Fri, 17 Apr 2015 17:07:31 +0200 (CEST) Received: from [10.10.1.112] (cacatoes.act-europe.fr [10.10.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 00ABB2DB30BF; Fri, 17 Apr 2015 17:07:31 +0200 (CEST) Message-ID: <553121B2.1040406@adacore.com> Date: Fri, 17 Apr 2015 15:07:00 -0000 From: Pierre-Marie de Rodat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yao Qi CC: Joel Brobecker , GDB Patches Subject: Re: [PATCH] Do not consider reference types as dynamic References: <54FEDC09.3050106@adacore.com> <20150323133627.GG5438@adacore.com> <551BB1C9.10006@adacore.com> <551E5309.7090509@adacore.com> <86k2xbrpzs.fsf@gmail.com> <5530EC8C.1070308@adacore.com> In-Reply-To: <5530EC8C.1070308@adacore.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00681.txt.bz2 On 04/17/2015 01:20 PM, Pierre-Marie de Rodat wrote: >> This patch causes a regression in gdb.cp/vla-cxx.exp unfortunately, >> >> print vlaref^M >> $2 = (int (&)[variable length]) @0x3fffffffe900: {5, 7, 9}^M >> (gdb) FAIL: gdb.cp/vla-cxx.exp: print vlaref >> >> which is shown by buildbot >> https://sourceware.org/ml/gdb-testers/2015-q2/msg00360.html This is tough! For the record, I did not notice this regression because I ran the testsuite with GCC's development branch, and this testcase was already failing with it. It works with GCC 4.9.2, though. So my understanding was that types are dynamic when we need runtime information to decode them properly (memory layout, range bounds, etc). With this definition, reference types are never dynamic since they are actually mere pointers (static size, no dynamic semantics). Printing a reference value is supposed to automatically fetch and print the referenced object... and its type. This testcase also tells us that it's the "fully resolved type" that must be printed (I mean referenced types must be resolved, too). Here, we have "vlaref": a reference to a VLA (variable-length array), hence a reference to a dynamic type (the bounds and thus the size of the array are dynamic). Because of the "dynamic type" definition above, the referenced type is kept as-is during evaluation. And then at type-printing time, we use the dynamic referenced type, hence the "variable length" in the output. If the definition above is correct, then we should enhance typeprint.c/c-typeprint.c/etc. to resolve dynamic type as type printing goes in order to get the actual array bounds in the output. This means: propagating a (possibly null) value in a lot of functions and use it for type resolution when possible. I guess this would involve a big patch but would also cover the "ptype" case. I guess another way to "just get things working" would be to revert my previous patch and to enhance the dynamic property mechanism (dwarf2loc.h) to handle reference values that are not present in memory. For instance: extend the property_addr_info structure to hold either the address of objects (as today) or the address of the referenced object (for reference types). Thoughts? -- Pierre-Marie de Rodat