From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23592 invoked by alias); 30 Mar 2012 19:51:43 -0000 Received: (qmail 23581 invoked by uid 22791); 30 Mar 2012 19:51:42 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Mar 2012 19:51:21 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2UJpIKX010441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2012 15:51:18 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2UJpGdC000579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2012 15:51:17 -0400 From: Tom Tromey To: Kevin Pouget Cc: gdb-patches@sourceware.org, pmuldoon@redhat.com, Eli Zaretskii Subject: Re: [PATCH] Add bp_location to Python interface References: <83r4z8eqoa.fsf@gnu.org> Date: Fri, 30 Mar 2012 19:51:00 -0000 In-Reply-To: (Kevin Pouget's message of "Fri, 27 Jan 2012 13:47:07 +0100") Message-ID: <87zkaxn9zf.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2012-03/txt/msg01067.txt.bz2 >>>>> "Kevin" == Kevin Pouget writes: Kevin> ping I'm sorry about the long delay on this. Kevin> free_bp_location (struct bp_location *loc) [...] Kevin> + gdbpy_bplocation_free (loc); I wonder whether tying these wrapper objects to the bp_location is really best. We do take this approach for many other objects exposed to Python, but those objects tend to be rather long-lived, and also to some extent visible across gdb -- as opposed to breakpoint locations, which are entirely managed by the breakpoint module. A different approach would be to instantiate and fill in the location objects when the 'location' method is called, and give them "copy" semantics instead. I'm not totally convinced either way, and I would like to know what you think about this. Kevin> +@findex gdb.locations Kevin> +@defun gdb.locations () The "gdb." here seems incorrect. This is a method on Breakpoint. Kevin> +Return a tuple containing a sequence of @code{gdb.BpLocation} objects "tuple containing a sequence" sounds weird. I would say just "a sequence" and not specify that it must be a tuple; it is commonplace in Python to operate on sequences generically, and we might as well leave ourselves whatever leeway we reasonably can. Kevin> +@defvar BpLocation.inferior Locations are really tied to program spaces, not inferiors. Offhand it seems to me that we should respect this in the API. Kevin> +bplocpy_breakpoint_deleted (struct breakpoint *b) { Wrong brace placement. Kevin> + tuple = PyList_AsTuple (list); Kevin> + Py_DECREF (list); In keeping with the doc change, you could just return the list here, rather than convert to a tuple. Kevin> +gdb_test "py print len(gdb.breakpoints())" "1" "ensure that threre is only one BP" Typo, "threre". Also the line should be split, here and elsewhere in the .exp. Kevin> +# how to check address location ? != address(main) It is tricky due to prologues, but you could check the output of "info symbol" on the address and see that it is "main". Tom