public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb/python: break more dependencies between gdbpy_initialize_* functions Date: Thu, 20 Oct 2022 15:58:10 +0000 (GMT) [thread overview] Message-ID: <20221020155810.C65CB3850227@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8a3b17063e86ba7687896de7b5de870006a02ef5 commit 8a3b17063e86ba7687896de7b5de870006a02ef5 Author: Andrew Burgess <aburgess@redhat.com> Date: Wed Sep 21 16:23:02 2022 +0100 gdb/python: break more dependencies between gdbpy_initialize_* functions 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. Diff: --- 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 0255bd1fead..fdbff5cf6bf 100644 --- a/gdb/python/py-finishbreakpoint.c +++ b/gdb/python/py-finishbreakpoint.c @@ -403,6 +403,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 c2ac96de326..06357cc8c0b 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
reply other threads:[~2022-10-20 15:58 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221020155810.C65CB3850227@sourceware.org \ --to=aburgess@sourceware.org \ --cc=gdb-cvs@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: linkBe 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).