From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128876 invoked by alias); 29 Nov 2018 21:52:51 -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 128851 invoked by uid 89); 29 Nov 2018 21:52:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:870 X-HELO: gateway34.websitewelcome.com Received: from gateway34.websitewelcome.com (HELO gateway34.websitewelcome.com) (192.185.148.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Nov 2018 21:52:48 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 527FC376D37 for ; Thu, 29 Nov 2018 15:52:47 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id SUEpgA29KBcCXSUEpgEoap; Thu, 29 Nov 2018 15:52:47 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TSfjxN7Dk9u5RYVwlvCgih2o2p9d8IvHxV0w3W/Em/Q=; b=uXA96o9kEvJjyaayJeppv2FV3L mbnrdLhgfg/DjlCe8nW01TmsS4hZojJLTYXGEVprKB4vQuJRbqrPqPGbgQm3Q4843GFCLiUOFtGV+ cmEp2manUTt9rt48GPsTkRggG; Received: from 97-122-190-66.hlrn.qwest.net ([97.122.190.66]:33734 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gSUEp-001n9S-2w; Thu, 29 Nov 2018 15:52:47 -0600 From: Tom Tromey To: Wei-min Pan Cc: Tom Tromey , Joel Brobecker , gdb-patches@sourceware.org Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string" References: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com> <20180125041431.tghhxefsgxnxh3l3@adacore.com> <1dfc87b0-353d-3388-a427-fee247dc79a5@oracle.com> <20180131074526.rqbsjxyxp3p26js5@adacore.com> <1d28e9c6-6377-0c46-6bce-1dc25a7fa2d5@oracle.com> <20180201075955.mnqxzmw4ktuy3f5d@adacore.com> <20181114235153.GB4336@adacore.com> <87tvjzae0u.fsf@tromey.com> <82a6d5fc-7152-88aa-115b-c767fd3f3569@oracle.com> Date: Thu, 29 Nov 2018 21:52:00 -0000 In-Reply-To: <82a6d5fc-7152-88aa-115b-c767fd3f3569@oracle.com> (Wei-min Pan's message of "Thu, 29 Nov 2018 13:10:19 -0800") Message-ID: <87lg5ba6vl.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-11/txt/msg00551.txt.bz2 >>>>> ">" == Wei-min Pan writes: >> Looks like we have at least 2 options: >> (1) Making sure the type is objfile-owned before calling copy_type in >> resolve_dynamic_range and resolve_dynamic_array as you suggested, or >> (2) Replacing the assert with an objfile-owned check in copy_type, similar >> to what copy_type_recursive does. Sorry, I still didn't read the whole thread... but I think what to do depends on what is happening. Most callers of copy_type are probably copying it to modify the copy. If this is the case, then maybe just removing the assert is ok. Or, maybe it makes sense to understand why the modified type isn't objfile-allocated in the first place. Could you recap? What is calling copy_type here and where did the type come from? Tom