Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFC 0/4] Better Python safety
@ 2026-02-22 19:49 Tom Tromey
  2026-02-22 19:49 ` [RFC 1/4] Add gdbpy_borrowed_ref Tom Tromey
                   ` (7 more replies)
  0 siblings, 8 replies; 18+ messages in thread
From: Tom Tromey @ 2026-02-22 19:49 UTC (permalink / raw)
  To: gdb-patches

This series is a rough draft showing how I think Python safety could
be improved.

The basic idea is to use C++ features: more fully use gdbpy_ref<> to
avoid reference-counting bugs, introduce a new gdbpy_borrowed_ref to
manage borrowed references; throw exceptions on failure rather than
explicit error checks; and finally wrap Python C APIs to enforce these
rules.

This approach also lets us implement Python methods in a more natural
style.  Explicit try/catch when calling gdb APIs is no longer needed,
and methods can simply return the appropriate type.

This series is nowhere near complete, but I did mostly convert
py-arch.c and py-frame.c.  (Discussion of some holes below.)

A nice example of the simplification is shown by
gdbpy_all_architecture_names, which is now just:

gdbpy_ref<>
gdbpy_all_architecture_names (gdbpy_borrowed_ref self)
{
  gdbpy_ref<> list = gdbpy_new_list (0);

  std::vector<const char *> name_list = gdbarch_printable_names ();
  for (const char *name : name_list)
    gdbpy_list_append (list, gdbpy_unicode_from_string (name));

 return list;
}

This shows pretty much all the features: no more error checking and it
returns a gdbpy_ref<> since that is convenient.


I think a few more features could still be added:

* I didn't handle single-argument methods in patch 3.  It's tempting
  to use METH_O but we have at least one that accepts "|s".

* I didn't write wrappers for tp_str / tp_repr ... or the methods in
  PyNumberMethods or PyMappingMethods.  This isn't difficult.

* I think the approach to handling subclasses of PyObject could be
  greatly improved.  In particular I think we could use real C++
  classes by judicious use of placement new and explicit destructor
  calls.  The "corresponding_object_type" stuff you'll see in here is
  sort of a gesture in this direction (though that code also helps
  with some type-safety elsewhere as well).  Essentially I think we
  could end up making new instances with just 'new'.

  I didn't want to really touch this until the stable ABI work related
  to type-instantiation is done.

* Finally gdb is using PyObject_New a lot but my reading while
  researching this series indicates that this is wrong.  However the
  wrongness is still (I guess temporarily) preserved in a wrapper in
  this series.

* There are some comments in the code where I didn't fully convert
  something.  This would just be a temporary state.

Let me know what you think.

Tom


^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2026-03-04 21:03 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-22 19:49 [RFC 0/4] Better Python safety Tom Tromey
2026-02-22 19:49 ` [RFC 1/4] Add gdbpy_borrowed_ref Tom Tromey
2026-02-24  4:57   ` Simon Marchi
2026-02-25  3:55     ` Tom Tromey
2026-02-25 15:24       ` Simon Marchi
2026-02-26  1:38       ` Tom Tromey
2026-02-22 19:49 ` [RFC 2/4] Add wrappers for some Python APIs Tom Tromey
2026-02-22 19:49 ` [RFC 3/4] Add constexpr functions to create PyMethodDef entries Tom Tromey
2026-02-22 19:49 ` [RFC 4/4] Convert some Python code to new-style Tom Tromey
2026-02-23 20:28 ` [RFC 0/4] Better Python safety Simon Marchi
2026-02-23 21:00 ` Simon Marchi
2026-02-23 23:23   ` Tom Tromey
2026-02-23 23:56     ` Tom Tromey
2026-02-24  1:05       ` Simon Marchi
2026-02-24 16:29         ` Tom Tromey
2026-02-23 21:22 ` Tom Tromey
2026-03-04 17:39 ` Matthieu Longo
2026-03-04 21:02   ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox