From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14046 invoked by alias); 6 Mar 2014 08:37:58 -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 14029 invoked by uid 89); 6 Mar 2014 08:37:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Mar 2014 08:37:56 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s268bsKQ002529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Mar 2014 03:37:54 -0500 Received: from localhost.localdomain (ovpn-112-30.ams2.redhat.com [10.36.112.30]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s268bpx2015764; Thu, 6 Mar 2014 03:37:53 -0500 Message-ID: <531833DE.2030407@redhat.com> Date: Thu, 06 Mar 2014 08:37:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Maxim Bublis CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] gdb/python: raise TypeError instead of abort() on calling .value() method for label symbol object References: <1393929360-31299-1-git-send-email-satori@yandex-team.ru> <1393929360-31299-3-git-send-email-satori@yandex-team.ru> <53161401.5080408@redhat.com> <07E7B14B-748D-4CF7-A8AD-623AF5D6E701@yandex-team.ru> In-Reply-To: <07E7B14B-748D-4CF7-A8AD-623AF5D6E701@yandex-team.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00150.txt.bz2 On 05/03/14 13:39, Maxim Bublis wrote: > >> This patch looks fine to me apart from one further small aside (please >> wait for a maintainer to approve your patch, regardless). In the >> documentation you note there are other types of symbol that can >> produce this error: e.g., SYMBOL_LOC_TYPEDEF. Can you please audit and >> include checks for all, while you are there? I noticed only the >> explicit LOC_LABEL check in the patch above. > > There is already implemented similar behavior for LOC_TYPEDEF, so no additional work here should be done. > On the other hand there is no testcase for typedef symbol object .value() method call. > Maybe you could provide me a help with writing such testcase as I do not quietly understand how typedef symbol object could be retrieved. That's fine, if it is already implemented. I think the above should be tested, but it represents a segue to your patch functionality, so should not block it. I am fine with the patch in the second revision. Please wait for a maintainer to give the go ahead. Cheers, Phil