From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5972 invoked by alias); 8 May 2014 21:09:19 -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 5943 invoked by uid 89); 8 May 2014 21:09:18 -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 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 08 May 2014 21:09:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2B7B91161A8; Thu, 8 May 2014 17:09:15 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id odWD2OyOlype; Thu, 8 May 2014 17:09:15 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 02CAB1161A7; Thu, 8 May 2014 17:09:14 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B773DE0463; Thu, 8 May 2014 14:09:14 -0700 (PDT) Date: Thu, 08 May 2014 21:09:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] handle VLA in a struct or union Message-ID: <20140508210914.GE4063@adacore.com> References: <1399574816-12845-1-git-send-email-tromey@redhat.com> <1399574816-12845-3-git-send-email-tromey@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1399574816-12845-3-git-send-email-tromey@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-05/txt/msg00101.txt.bz2 > However, before this goes in, I'd like to understand the oddity > pointed out by a change in is_dynamic_type. That is, this test: > > /* This can happen with Ada for reasons unknown. */ > && TYPE_FIELD_TYPE (type, i) != NULL > > is needed to avoid a crash with the Ada "iwide.exp" test. This type: > > (top-gdb) p real_type.main_type.name > $15 = 0x7ffff0354c6d "ada__tags__type_specific_data___XVE" > > ... has a seemingly invalid field: > > (top-gdb) p real_type.main_type.nfields > $9 = 13 > [...] > (top-gdb) p real_type.main_type.flds_bnds.fields[12] > $12 = { > loc = { > bitpos = 576, > enumval = 576, > physaddr = 576, > physname = 0x240
, > dwarf_block = 0x240 > }, > artificial = 0, > loc_kind = FIELD_LOC_KIND_BITPOS, > bitsize = 0, > type = 0x0, > name = 0x0 > } > > Joel, can you comment? Thanks. It's actually not the only testcase I see being impacted if I remove the check. What happens is that we're in the middle of resolving this very type (what we have been calling creating a fixed version of the type). While doing so, we do... if (dval0 == NULL) { /* rtype's length is computed based on the run-time value of discriminants. If the discriminants are not initialized, the type size may be completely bogus and GDB may fail to allocate a value for it. So check the size first before creating the value. */ check_size (rtype); dval = value_from_contents_and_address (rtype, valaddr, address); rtype = value_type (dval); } ... where rtype is the resolved type being constructed, and therefore a type that isn't completely consistent yet. the call to value_from_contents_and_address eventually leads to the is_dynamic_type call. I think I need to review that code, as I do that a litte little later in the function again. I'll send another update when I have more info on this. -- Joel