From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124342 invoked by alias); 2 Feb 2018 01:14:32 -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 124323 invoked by uid 89); 2 Feb 2018 01:14:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=firm, H*u:6.1, H*UA:6.1 X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Feb 2018 01:14:30 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w121E61b059807; Fri, 2 Feb 2018 01:14:26 GMT Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2fvahc8r8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Feb 2018 01:14:26 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w121EPN8021068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 2 Feb 2018 01:14:26 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w121EOY5004212; Fri, 2 Feb 2018 01:14:24 GMT Received: from [10.159.150.36] (/10.159.150.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Feb 2018 17:14:24 -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: Fri, 02 Feb 2018 01:14:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8792 signatures=668660 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=796 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802020008 X-SW-Source: 2018-02/txt/msg00027.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. I see, thanks for the clarification. But it doesn't seem to be the case when we have a declaration like "unsigned char p[] = "abc";". The array type and its element type will split between an objfile and an 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! What needs to be done then is to pick the correct obstack, from either objfile_obstack or gdbarch->obstack, when copying the dynamic property list? >> 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. > Since the type to be copied needs to be objfile-owned in copy_type(), will it still trigger the assertion if the complete type was created and owned by an arch? Thanks.