Re: [RFC] Allowing GDB to use a more recent version of Python at runtime than it was compiled with

[Tom Tromey <tom@tromey.com>]

>>>>> "Matthieu" == Matthieu Longo <matthieu.longo@arm.com> writes:

Matthieu> ## End goal
Matthieu> Allowing GDB to use a more recent version of Python at runtime than it
Matthieu> was compiled with.

FWIW I've looked at this several times over the years.  See:

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

Matthieu> I got errors about Py_buffer and PyBuffer_Release (part of the Stable
Matthieu> ABI (including all members) since version 3.11, so changed
Matthieu> Py_LIMITED_API to 0x030b0000):
Matthieu> https://docs.python.org/3/c-api/buffer.html#c.Py_buffer

This is new since the last time I looked.

Note that gdb still supports a very old Python by default -- like 3.4 I
think.  This is bad but it is hard to change.

Matthieu> There might be more issues as the build process stopped and didn't go
Matthieu> over all the files in gdb/python.

Yeah, there's the readline stuff mentioned in the bug.  Maybe this could
be disabled.  One idea might be to have a configure flag requesting the
stable API and then just drop this module in this case.

This idea might 'interface' with the 3.4 requirement above.  Like, we
can have a fallback mode in the source for people building against older
versions of Python.

Matthieu> Making the usage of PyTypeObject opaque would consist in transforming
Matthieu> the declaration of those PyTypeObjects to a static PyType_Slot and
Matthieu> PyType_Spec equivalent, and then creating a PyObject* by calling
Matthieu> PyType_FromSpec() instead of PyModule_AddObject(), which is, by the
Matthieu> way, "soft deprecated" since Python 3.13.

Yes, converting to PyType_FromSpec would be fine.

Matthieu> Following the logic of PEP-384, linking against the Python limited C
Matthieu> API means linking against libpython3.so, not libpython3.x.so

Matthieu> With in the current state of Python packaging, this creates issues at
Matthieu> different stages:

I don't know what to do about this one.  But I guess one idea would be
that gdb could adopt the changes that make sense, and then you could
handle the build-time madness for your own builds.  Then this could be
improved in gdb as the upstream Python/distro situation develops.

Matthieu> - testing. I have had a look at the test coverage of the Python GDB
Matthieu>   API, and it seems ok at a first glance. Please let me know if you
Matthieu>   can see any difficulty with the current coverage.

How did you test coverage?

I used to routinely to --coverage builds and test these, but they
haven't been reliable for me for a couple of years now :-(

Matthieu> - any performance impact caused by this transition that I should be
Matthieu>   aware of. And how did you measure it ? How critical are performances
Matthieu>   regarding the Python limited C API ?

I would not worry about this at all.

Feel free to update the bug with your findings.  Also if you send
patches, of course mention the bug so it's auto-updated.

good luck,
Tom