diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-12-06 16:57:11 +0100 |
---|---|---|
committer | Alexandra Hájková <ahajkova@redhat.com> | 2023-12-13 10:46:44 +0100 |
commit | 8170efad364aa8e062cba3b722b81aca9eda8cf5 (patch) | |
tree | de4dfc67182ebf341a5be334c1c345379b5c2092 /gdb/tui | |
parent | 7ae9ecfd80104a793ed1d836fd4dc0aa1a9c7832 (diff) | |
download | binutils-8170efad364aa8e062cba3b722b81aca9eda8cf5.zip binutils-8170efad364aa8e062cba3b722b81aca9eda8cf5.tar.gz binutils-8170efad364aa8e062cba3b722b81aca9eda8cf5.tar.bz2 |
gdb/python: avoid use of _PyOS_ReadlineTState
In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState,
however, this variable is no longer public in Python 3.13, and so GDB
no longer builds.
We are making use of _PyOS_ReadlineTState in order to re-acquire the
Python Global Interpreter Lock (GIL). The _PyOS_ReadlineTState
variable is set in Python's outer readline code prior to calling the
user (GDB) supplied readline callback function, which for us is
gdbpy_readline_wrapper. The gdbpy_readline_wrapper function is called
without the GIL held.
Instead of using _PyOS_ReadlineTState, I propose that we switch to
calling PyGILState_Ensure() and PyGILState_Release(). These functions
will acquire the GIL based on the current thread. I think this should
be sufficient; I can't imagine why we'd be running
gdbpy_readline_wrapper on one thread on behalf of a different Python
thread.... that would be unexpected I think.
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/tui')
0 files changed, 0 insertions, 0 deletions