From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77080 invoked by alias); 1 Feb 2018 01:46:36 -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 77066 invoked by uid 89); 1 Feb 2018 01:46:35 -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,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=xc, firm, H*u:6.1, H*UA:6.1 X-HELO: aserp2130.oracle.com Received: from aserp2130.oracle.com (HELO aserp2130.oracle.com) (141.146.126.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Feb 2018 01:46:34 +0000 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w111gc7D019210; Thu, 1 Feb 2018 01:46:30 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2fuqkfra3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 01 Feb 2018 01:46:30 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w111kTfu021552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 1 Feb 2018 01:46:29 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w111kQB5003431; Thu, 1 Feb 2018 01:46:26 GMT Received: from [10.39.212.20] (/10.39.212.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jan 2018 17:46:26 -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> From: Wei-min Pan Message-ID: <1d28e9c6-6377-0c46-6bce-1dc25a7fa2d5@oracle.com> Date: Thu, 01 Feb 2018 01:46: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: <20180131074526.rqbsjxyxp3p26js5@adacore.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8791 signatures=668659 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=931 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802010018 X-SW-Source: 2018-02/txt/msg00000.txt.bz2 On 1/30/2018 11:45 PM, Joel Brobecker wrote: >> 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. 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. > 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)) >>> 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. 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. 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. > > I can help taking a look, but I'm a little tied up this week... > I'd really appreciate it if you can take a look at your convenience. It doesn't have to be this week. Thanks.