public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug python/18385] no way to get locations from a breakpoint
Date: Thu, 28 Jul 2022 17:48:02 +0000	[thread overview]
Message-ID: <bug-18385-4717-4xA1pWPkdu@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-18385-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=18385

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e5213e2c851c295c5e4c3e9b52606c1012029b67

commit e5213e2c851c295c5e4c3e9b52606c1012029b67
Author: Simon Farre <simon.farre.cx@gmail.com>
Date:   Tue Jun 7 13:57:48 2022 +0200

    gdb/python: Add BreakpointLocation type

    PR python/18385

    v7:
    This version addresses the issues pointed out by Tom.

    Added nullchecks for Python object creations.

    Changed from using PyLong_FromLong to the gdb_py-versions.

    Re-factored some code to make it look more cohesive.

    Also added the more safe Python reference count decrement PY_XDECREF,
    even though the BreakpointLocation type is never instantiated by the
    user (explicitly documented in the docs) decrementing < 0 is made
    impossible with the safe call.

    Tom pointed out that using the policy class explicitly to decrement a
    reference counted object was not the way to go, so this has instead been
    wrapped in a ref_ptr that handles that for us in blocpy_dealloc.

    Moved macro from py-internal to py-breakpoint.c.

    Renamed section at the bottom of commit message "Patch Description".

    v6:
    This version addresses the points Pedro gave in review to this patch.

    Added the attributes `function`, `fullname` and `thread_groups`
    as per request by Pedro with the argument that it more resembles the
    output of the MI-command "-break-list".  Added documentation for these
attributes.

    Cleaned up left overs from copy+paste in test suite, removed hard coding
    of line numbers where possible.

    Refactored some code to use more c++-y style range for loops
    wrt to breakpoint locations.

    Changed terminology, naming was very inconsistent. Used a variety of
"parent",
    "owner". Now "owner" is the only term used, and the field in the
    gdb_breakpoint_location_object now also called "owner".

    v5:

    Changes in response to review by Tom Tromey:
    - Replaced manual INCREF/DECREF calls with
      gdbpy_ref ptrs in places where possible.
    - Fixed non-gdb style conforming formatting
    - Get parent of bploc increases ref count of parent.
    - moved bploc Python definition to py-breakpoint.c

    The INCREF of self in bppy_get_locations is due
    to the individual locations holding a reference to
    it's owner. This is decremented at de-alloc time.

    The reason why this needs to be here is, if the user writes
    for instance;

    py loc = gdb.breakpoints()[X].locations[Y]

    The breakpoint owner object is immediately going
    out of scope (GC'd/dealloced), and the location
    object requires it to be alive for as long as it is alive.

    Thanks for your review, Tom!

    v4:
    Fixed remaining doc issues as per request
    by Eli.

    v3:
    Rewritten commit message, shortened + reworded,
    added tests.

    Patch Description

    Currently, the Python API lacks the ability to
    query breakpoints for their installed locations,
    and subsequently, can't query any information about them, or
    enable/disable individual locations.

    This patch solves this by adding Python type gdb.BreakpointLocation.
    The type is never instantiated by the user of the Python API directly,
    but is produced by the gdb.Breakpoint.locations attribute returning
    a list of gdb.BreakpointLocation.

    gdb.Breakpoint.locations:
    The attribute for retrieving the currently installed breakpoint
    locations for gdb.Breakpoint. Matches behavior of
    the "info breakpoints" command in that it only
    returns the last known or currently inserted breakpoint locations.

    BreakpointLocation contains 7 attributes

    6 read-only attributes:
    owner: location owner's Python companion object
    source: file path and line number tuple: (string, long) / None
    address: installed address of the location
    function: function name where location was set
    fullname: fullname where location was set
    thread_groups: thread groups (inferiors) where location was set.

    1 writeable attribute:
    enabled: get/set enable/disable this location (bool)

    Access/calls to these, can all throw Python exceptions (documented in
    the online documentation), and that's due to the nature
    of how breakpoint locations can be invalidated
    "behind the scenes", either by them being removed
    from the original breakpoint or changed,
    like for instance when a new symbol file is loaded, at
    which point all breakpoint locations are re-created by GDB.
    Therefore this patch has chosen to be non-intrusive:
    it's up to the Python user to re-request the locations if
    they become invalid.

    Also there's event handlers that handle new object files etc, if a Python
    user is storing breakpoint locations in some larger state they've
    built up, refreshing the locations is easy and it only comes
    with runtime overhead when the Python user wants to use them.

    gdb.BreakpointLocation Python type
    struct "gdbpy_breakpoint_location_object" is found in python-internal.h

    Its definition, layout, methods and functions
    are found in the same file as gdb.Breakpoint (py-breakpoint.c)

    1 change was also made to breakpoint.h/c to make it possible
    to enable and disable a bp_location* specifically,
    without having its LOC_NUM, as this number
    also can change arbitrarily behind the scenes.

    Updated docs & news file as per request.

    Testsuite: tests the .source attribute and the disabling of
    individual locations.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385


    Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2022-07-28 17:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 22:35 [Bug python/18385] New: " tromey at sourceware dot org
2022-04-20 14:57 ` [Bug python/18385] " simon.farre.cx at gmail dot com
2022-07-12 20:01 ` tromey at sourceware dot org
2022-07-13 10:03 ` simon.farre.cx at gmail dot com
2022-07-28 17:48 ` cvs-commit at gcc dot gnu.org [this message]
2022-07-28 17:48 ` tromey at sourceware dot org

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=bug-18385-4717-4xA1pWPkdu@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).