From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25873 invoked by alias); 31 Jan 2018 07:45:42 -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 25784 invoked by uid 89); 31 Jan 2018 07:45:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pc, firm, satisfactory, management 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; Wed, 31 Jan 2018 07:45:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 32D9B563BD; Wed, 31 Jan 2018 02:45:31 -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 0yGlEE1bAfWA; Wed, 31 Jan 2018 02:45:31 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C1D82563BB; Wed, 31 Jan 2018 02:45:30 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 911F683307; Wed, 31 Jan 2018 11:45:26 +0400 (+04) Date: Wed, 31 Jan 2018 07:45:00 -0000 From: Joel Brobecker To: Wei-min Pan Cc: gdb-patches@sourceware.org Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string" Message-ID: <20180131074526.rqbsjxyxp3p26js5@adacore.com> References: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com> <20180125041431.tghhxefsgxnxh3l3@adacore.com> <1dfc87b0-353d-3388-a427-fee247dc79a5@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1dfc87b0-353d-3388-a427-fee247dc79a5@oracle.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-01/txt/msg00647.txt.bz2 > Is there any reason why the gdbarch structure, which won't be freed > until the corresponding architecture is, needs to have a lifetime that > matches the objfiles? Unfortunately, I only have vague answers for you. I know it's not as satisfactory as a firm one, but I haven't had time to investigate further. My feeling is that it's (intuitively) a bad idea to start mixing and matching the ownership type for a give type chain. It just muddies the waters, and makes memory management more complex. Parallel to that, there is another obstacle if you want to enhance copy_type to handle arch-owned types, as the current implementation explicitly assumes that the type is objfile-owned, and therefore references its objfile's obstack: if (TYPE_DYN_PROP_LIST (type) != NULL) TYPE_DYN_PROP_LIST (new_type) = copy_dynamic_prop_list (&TYPE_OBJFILE (type) -> objfile_obstack, TYPE_DYN_PROP_LIST (type)); > > 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? > > > Yes, it does fix my problem of gdb asserting on the "set {char[]}$pc="hi"" > command, as > reported in the PR, Good! > but still asserts on a slightly modified "set {unsigned char[]}$pc="hi" > command. It's should be something fairly similar. Can you track down which type it is which is arch-owned, and where it comes from? I have a feeling that there is a simple fix similar to mine to be made that would fix that. I can help taking a look, but I'm a little tied up this week... -- Joel