mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2026-08-27 00:26:02 -04:00
All of our custom Python types are created as structs, like this:
struct some_new_type : public PyObject
{
... various fields ...
};
Then instances of this struct are created by calling PyObject_New,
either directly within GDB's C++ code, or within Python when a user's
Python script creates an instance of that class.
The problem is that Python is written in C, and PyObject_New doesn't
call any constructors for `some_new_type`, nor for any of the fields
within `some_new_type`.
If `some_new_type` is Plain Old Data (POD), then this is fine. Or, to
be more C++ specific, if `some_new_type` is trivially default
constructable, then we're fine.
But if a field within `some_new_type` has a non-trivial constructor,
then we're in trouble as that constructor will never be run.
An example of a problematic field type is frame_info_ptr. The
constructor for this type registers the new object with a central
management object, recording the `this` pointer, using this type within
`some_new_type` will not work as expected; frame invalidation will not
show up within the frame_info_ptr as you might expect.
And so, this type trait exists. Whenever a struct is created to define
a new Python type we should add a line like:
static_assert (gdb::is_python_allocatable_v<some_new_type>);
This will fail if any field of `some_new_type` are unsuitable for this
use.
We don't actually check is_trivially_default_constructible here. Some
types, e.g. ui_file_style::color, have non-trivial (or no default)
constructors, but are still safe to use within `some_new_type` because
their constructors just initialise data fields; there's nothing
"special" that the constructor does that cannot be achieved by
assigning the fields after creation with PyObject_New.
What actually matters is that the type is trivially destructible
(Python won't call C++ destructors, so destructors with side effects,
like deregistering from a list, would be skipped) and trivially
copyable (Python may copy objects with memcpy). Types like
frame_info_ptr, whose constructors and destructors have side effects
such as registering with a central management object, will be caught
because they are neither trivially destructible nor trivially copyable.
Simple POD types like ui_file_style are trivially destructible and
copyable, so pass this trait.
This commit adds the new type trait, and makes use of it in all cases
but one, pending_frame_object in python/py-unwind.c, has a field of
type frame_info_ptr, which is currently broken. This will be fixed,
and the static_assert added, in the next commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
||
|---|---|---|
| .. | ||
| lib/gdb | ||
| py-all-events.def | ||
| py-arch.c | ||
| py-auto-load.c | ||
| py-block.c | ||
| py-bpevent.c | ||
| py-breakpoint.c | ||
| py-cmd.c | ||
| py-color.c | ||
| py-color.h | ||
| py-connection.c | ||
| py-continueevent.c | ||
| py-corefile.c | ||
| py-dap.c | ||
| py-disasm.c | ||
| py-event-types.def | ||
| py-event.c | ||
| py-event.h | ||
| py-events.h | ||
| py-evtregistry.c | ||
| py-evts.c | ||
| py-exitedevent.c | ||
| py-finishbreakpoint.c | ||
| py-frame.c | ||
| py-framefilter.c | ||
| py-function.c | ||
| py-gdb-readline.c | ||
| py-inferior.c | ||
| py-infevents.c | ||
| py-infthread.c | ||
| py-instruction.c | ||
| py-instruction.h | ||
| py-lazy-string.c | ||
| py-linetable.c | ||
| py-membuf.c | ||
| py-mi.c | ||
| py-micmd.c | ||
| py-newobjfileevent.c | ||
| py-obj-type.c | ||
| py-obj-type.h | ||
| py-objfile.c | ||
| py-param.c | ||
| py-prettyprint.c | ||
| py-progspace.c | ||
| py-record-btrace.c | ||
| py-record-btrace.h | ||
| py-record-full.c | ||
| py-record-full.h | ||
| py-record.c | ||
| py-record.h | ||
| py-ref.h | ||
| py-registers.c | ||
| py-signalevent.c | ||
| py-stopevent.c | ||
| py-stopevent.h | ||
| py-style.c | ||
| py-symbol.c | ||
| py-symtab.c | ||
| py-threadevent.c | ||
| py-tui.c | ||
| py-type.c | ||
| py-uiout.h | ||
| py-unwind.c | ||
| py-utils.c | ||
| py-value.c | ||
| py-varobj.c | ||
| py-xmethods.c | ||
| python-config.py | ||
| python-internal.h | ||
| python-limited-api-missing.h | ||
| python-traits.h | ||
| python.c | ||
| python.h | ||