From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86726 invoked by alias); 25 Jan 2018 04:14:39 -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 86716 invoked by uid 89); 25 Jan 2018 04:14:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:1516844, H*MI:sk:1516844, H*f:sk:1516844 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 ESMTP; Thu, 25 Jan 2018 04:14:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DEBA4560BA; Wed, 24 Jan 2018 23:14:35 -0500 (EST) 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 ZltzySmDwE9Q; Wed, 24 Jan 2018 23:14:35 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 79DD656082; Wed, 24 Jan 2018 23:14:35 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 273588330C; Thu, 25 Jan 2018 08:14:31 +0400 (+04) Date: Thu, 25 Jan 2018 04:14:00 -0000 From: Joel Brobecker To: Weimin Pan Cc: gdb-patches@sourceware.org Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string" Message-ID: <20180125041431.tghhxefsgxnxh3l3@adacore.com> References: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-01/txt/msg00497.txt.bz2 > To support C99 VLA, function value_from_contents_and_address() was > modified to add a call to resolve_dynamic_type(), which in turn > calls resolve_dynamic_array() to resolve the dynamic array bounds > to static values. But the problem arises when function copy_type(), > called by resolve_dynamic_array(), expects the type to be copied > to have an associated objfile from which the new type is allocated, > or asserts. Since type char[] doesn't have an associated objfile > when the following gdb command: > > (gdb) set {char[]}$pc="hello" > > was issued, gdb asserts. > > The gdb_assert (TYPE_OBJFILE_OWNED (type)) line in copy_type() doesn't > look necessary or correct since space needed for the new type could be > allocated from either the type's objfile if it exists or gdbarch if > it doesn't, similar to what alloc_type_copy(), which is called after > gdb_assert() in copy_type(), does. Removing gdb_assert() fixes the > problem. I think removing the assert just shifts the issue elsewhere. Basically, you want the lifetime of the new type to match the lifetime of the object using it. The gdbarch structure has a lifetime that's different from objfiles. I happen to have hit the same issue as you, but from an Ada expression, and sent it a fix not long ago: https://www.sourceware.org/ml/gdb-patches/2018-01/msg00240.html Does it fix your problem too? -- Joel