From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 2/3] gdb/python: break more dependencies between gdbpy_initialize_* functions
Date: Sun, 2 Oct 2022 17:53:04 +0100 [thread overview]
Message-ID: <1e89f7f71a8170a1529697d1bfc9d971d89978f9.1664729134.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1664729134.git.aburgess@redhat.com>
In a later commit in this series I will propose removing all of the
explicit gdbpy_initialize_* calls from python.c and replace these
calls with a more generic mechanism.
One of the side effects of this generic mechanism is that the order in
which the various Python sub-systems within GDB are initialized is no
longer guaranteed.
On the whole I don't think this matters, most of the sub-systems are
independent of each other, though testing did reveal a few places
where we did have dependencies, though I don't think those
dependencies were explicitly documented in comment anywhere.
This commit is similar to the previous one, and fixes the second
dependency issue that I found.
In this case the finish_breakpoint_object_type uses the
breakpoint_object_type as its tp_base, this means that
breakpoint_object_type must have been initialized with a call to
PyType_Ready before finish_breakpoint_object_type can be initialized.
Previously we depended on the ordering of calls to
gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
python.c.
After this commit a new function gdbpy_breakpoint_init_breakpoint_type
exists, this function ensures that breakpoint_object_type has been
initialized, and can be called from any gdbpy_initialize_* function.
I feel that this change makes the dependency explicit, which I think
is a good thing.
There should be no user visible changes after this commit.
---
gdb/python/py-breakpoint.c | 23 +++++++++++++++++++++--
gdb/python/py-finishbreakpoint.c | 3 +++
gdb/python/python-internal.h | 12 ++++++++++++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c
index dd4519a1b05..7a757432948 100644
--- a/gdb/python/py-breakpoint.c
+++ b/gdb/python/py-breakpoint.c
@@ -989,6 +989,26 @@ build_bp_list (struct breakpoint *b, PyObject *list)
return PyList_Append (list, bp) == 0;
}
+/* See python-internal.h. */
+
+bool
+gdbpy_breakpoint_init_breakpoint_type ()
+{
+ if (breakpoint_object_type.tp_new == nullptr)
+ {
+ breakpoint_object_type.tp_new = PyType_GenericNew;
+ if (PyType_Ready (&breakpoint_object_type) < 0)
+ {
+ /* Reset tp_new back to nullptr so future calls to this function
+ will try calling PyType_Ready again. */
+ breakpoint_object_type.tp_new = nullptr;
+ return false;
+ }
+ }
+
+ return true;
+}
+
/* Static function to return a tuple holding all breakpoints. */
PyObject *
@@ -1216,8 +1236,7 @@ gdbpy_initialize_breakpoints (void)
{
int i;
- breakpoint_object_type.tp_new = PyType_GenericNew;
- if (PyType_Ready (&breakpoint_object_type) < 0)
+ if (!gdbpy_breakpoint_init_breakpoint_type ())
return -1;
if (gdb_pymodule_addobject (gdb_module, "Breakpoint",
diff --git a/gdb/python/py-finishbreakpoint.c b/gdb/python/py-finishbreakpoint.c
index c4b043f5bfe..67637f16a39 100644
--- a/gdb/python/py-finishbreakpoint.c
+++ b/gdb/python/py-finishbreakpoint.c
@@ -408,6 +408,9 @@ bpfinishpy_handle_exit (struct inferior *inf)
int
gdbpy_initialize_finishbreakpoints (void)
{
+ if (!gdbpy_breakpoint_init_breakpoint_type ())
+ return -1;
+
if (PyType_Ready (&finish_breakpoint_object_type) < 0)
return -1;
diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index d624b23fdc5..a4f54e78268 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -290,6 +290,18 @@ extern PyTypeObject frame_object_type
extern PyTypeObject thread_object_type
CPYCHECKER_TYPE_OBJECT_FOR_TYPEDEF ("thread_object");
+/* Ensure that breakpoint_object_type is initialized and return true. If
+ breakpoint_object_type can't be initialized then set a suitable Python
+ error and return false.
+
+ This function needs to be called from any gdbpy_initialize_* function
+ that wants to reference breakpoint_object_type. After all the
+ gdbpy_initialize_* functions have been called then breakpoint_object_type
+ is guaranteed to have been initialized, and this function does not need
+ calling before referencing breakpoint_object_type. */
+
+extern bool gdbpy_breakpoint_init_breakpoint_type ();
+
struct gdbpy_breakpoint_object
{
PyObject_HEAD
--
2.25.4
next prev parent reply other threads:[~2022-10-02 16:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-02 16:53 [PATCH 0/3] New mechanism to initialise Python components in GDB Andrew Burgess
2022-10-02 16:53 ` [PATCH 1/3] gdb/python: break dependencies between gdbpy_initialize_* functions Andrew Burgess
2022-10-14 17:06 ` Tom Tromey
2022-10-20 15:58 ` Andrew Burgess
2022-10-02 16:53 ` Andrew Burgess [this message]
2022-10-14 17:06 ` [PATCH 2/3] gdb/python: break more " Tom Tromey
2022-10-20 15:59 ` Andrew Burgess
2022-10-02 16:53 ` [PATCH 3/3] gdb/python: add gdbpy_register_subsystem mechanism Andrew Burgess
2022-10-14 17:20 ` Tom Tromey
2022-10-21 13:17 ` [PATCHv2] gdb/python: add mechanism to manage Python initialization functions Andrew Burgess
2023-04-17 15:26 ` Tom Tromey
2023-05-05 17:27 ` Andrew Burgess
2023-05-05 20:07 ` Tom Tromey
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=1e89f7f71a8170a1529697d1bfc9d971d89978f9.1664729134.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@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).