From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117814 invoked by alias); 14 Nov 2018 23:38:59 -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 117799 invoked by uid 89); 14 Nov 2018 23:38:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=xc, ownership, firm, H*UA:6.1 X-HELO: aserp2120.oracle.com Received: from aserp2120.oracle.com (HELO aserp2120.oracle.com) (141.146.126.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Nov 2018 23:38:56 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wAENcpVU055643; Wed, 14 Nov 2018 23:38:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=cVKCzeEKp05BO2AgaIG2QIrxAmuT9cuxmDjr0W6GGEY=; b=XT8nW4xFEUcOxym7d3Osq+RMZN/l+ETaeyU9jWaPOdTX0lfabpmblskSbValgz8cZ9Em aIAZ9aMCA9WAmV0Yqi+umWSrlLCqSC0gH7B3kmKDjfDfhSuVGLog7gHEHGt+eF+G3LNh hNyM2usFF5S6nRFp7RyV1UVdvmJa/Egyn0WWTS3XLOVYAIyFd/fwAB+o9Le9+RZeec6D MhUexPqRZRwe3HnJJW2J7KPHIQBJ8GBaDBjLVxLQAqFsLZgmtA+dlRTcH29eZm5yjVcZ qzi4s1AmE0sKK29PRTZZM9yY/rApJ6lC+31haaLwV4uZUPrrn2Zs3uvHgfgl0Hx7CQsC Uw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2nr7cs6hw8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 23:38:51 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wAENco8S025285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 23:38:51 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAENcoxN004266; Wed, 14 Nov 2018 23:38:50 GMT Received: from [10.159.145.149] (/10.159.145.149) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Nov 2018 15:38:50 -0800 Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string" To: Joel Brobecker Cc: gdb-patches@sourceware.org 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> From: Wei-min Pan Message-ID: Date: Wed, 14 Nov 2018 23:38:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180201075955.mnqxzmw4ktuy3f5d@adacore.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-11/txt/msg00234.txt.bz2 On 1/31/2018 11:59 PM, Joel Brobecker wrote: >>> 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. >> Given there are functions such as arch_integer_type(), >> arch_character_type(), >> and arch_float_type() that can be used to add types to an arch, it doesn't >> seem terribly wrong to add a type which is not associated with any objfile >> to gdbarch? Also a type can actually exist in both an arch and an objfile. > I am not sure we understand each other. For me, what seems wrong > is the fact that we have an array type where part of the type is > objfile-owned, and part of it arch-owned. > > Creating arch-owned type is fine, as long as the entire type is > arch-owned. Sorry, I just don't see how it's possible to have an array type where part of the type is objfile-owned and part of it arch-owned. When an array type is copied, the space allocation depends on whether or not the element type is defined in the program. If it is defined, space for the index type, range type, and array type itself are all allocated from that object file. Otherwise, they are all allocated from the arch. > >>> 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)); >> Good point. The following statement >> >>   if (TYPE_DYN_PROP_LIST (type) != NULL) >> >> needs to be changed to: >> >>   if (TYPE_DYN_PROP_LIST (type) != NULL && TYPE_OBJFILE_OWNED(type)) > That would be wrong, because the resulting type would be missing > that dynamic property list, which means the resulting type would > be a complete copy of the original type. It's not so simple! > >> Your fix in lookup_array_range_type() takes care the case where >> "element_type" was owned by an objfile but still creates an arch-owned >> index type if it was not. > That is correct, and it is not a problem as long as the entire type > is consistent. > >> Here is the test case that comes with the PR: >> >> % cat x.c >> char p[] = "hello"; >> >> int main() >> { >>   return ((int)(p[0])); >> } >> >> Please note that the test case declares base type "char" which has an >> associated objfile and is picked up by lookup_symbol_aux() when >> command "set {char[]}$pc="hi" is parsed and eventually is passed as >> the element type argument to lookup_array_range_type(). Using any >> other type, such as "unsigned char", in that gdb command results in >> the element type that is picked up from gdbarch and has no associated >> objfile. > That is exactly the problem. At the point where it decides to use > an arch-owned type, it should check the type it is for, and whether > it is arch or objfile owned, and then create the type from there. > If my intuition is right, my patch should be a good example of what > needs to be done. >