From: Tom Tromey <tromey@redhat.com>
To: Kevin Pouget <kevin.pouget@gmail.com>
Cc: gdb-patches@sourceware.org, pmuldoon@redhat.com,
Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH] Add bp_location to Python interface
Date: Fri, 30 Mar 2012 19:51:00 -0000 [thread overview]
Message-ID: <87zkaxn9zf.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAPftXUJuT+m1G+9UGkzPpzo=rps2RMxXZkDVnUh17i9-G3YYgw@mail.gmail.com> (Kevin Pouget's message of "Fri, 27 Jan 2012 13:47:07 +0100")
>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> 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
next prev parent reply other threads:[~2012-03-30 19:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 10:17 Kevin Pouget
2011-12-08 13:39 ` Phil Muldoon
2011-12-08 14:28 ` Kevin Pouget
2011-12-08 14:56 ` Phil Muldoon
2011-12-09 13:49 ` Kevin Pouget
2011-12-09 14:15 ` Phil Muldoon
2011-12-13 15:55 ` Kevin Pouget
2012-01-09 11:47 ` Kevin Pouget
2012-01-09 17:23 ` Eli Zaretskii
2012-01-10 15:09 ` Kevin Pouget
2012-01-10 16:03 ` Kevin Pouget
2012-01-10 17:25 ` Eli Zaretskii
2012-01-11 10:16 ` Kevin Pouget
2012-01-11 10:27 ` Eli Zaretskii
2012-01-10 22:24 ` Doug Evans
2012-01-11 9:05 ` Kevin Pouget
2012-01-11 19:45 ` Doug Evans
2012-01-27 13:04 ` Kevin Pouget
2012-03-30 19:51 ` Tom Tromey [this message]
2012-04-03 10:35 ` Kevin Pouget
2012-04-03 12:15 ` Phil Muldoon
2012-04-03 14:43 ` Paul_Koning
2012-04-04 8:36 ` Kevin Pouget
2012-05-09 7:18 ` Kevin Pouget
2012-04-05 16:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zkaxn9zf.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=kevin.pouget@gmail.com \
--cc=pmuldoon@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox