Re: [PATCH v1 4/4] gdb/python: work around missing symbols not yet part of Python limited API

[Matthieu Longo <matthieu.longo@arm.com>]

On 17/04/2026 18:26, Tom Tromey wrote:
>>>>>> "Matthieu" == Matthieu Longo <matthieu.longo@arm.com> writes:
> 
> Matthieu> Since no limited API alternatives exist for these, and given their long
> Matthieu> history of ABI stability, one approach is to expose them in a GDB header
> Matthieu> and rely on their continued stability. While this is not without risk,
> Matthieu> it seems acceptable given the arguments above.
> 
> I'm not opposed to this at all but I wonder if there's some way we could
> arrange to check that this file doesn't get out of date.
> 

I don't see how we could do that.

However, we can make explicit the range of Python versions that are supported by this workaround header.
If GDB is compiled with the Python limited API enabled, and if CPython is a newer version that has 
never been tested, we could make it error so that someone has to publish a patch to update the range 
of supported versions in this file. It will force maintainers to look at this file for every new 
versions of CPython, and check whether there is any breaking change in the ABI.

> Like, is there some way we could have a file that includes both
> <Python.h> and this file but without defining Py_LIMITED_API?
> 

How would it help ?

> Or alternatively could we segregate the code that needs these APIs and
> compile that code without Py_LIMITED_API?  (Removing the need for this file?)

Moving gdb_PyInitializer into another CPP file and expose the class via the header is feasible.
For PyRun_InteractiveLoop() and PyOS_ReadlineFunctionPointer, it would be very awkward.

> > Tom

Matthieu