aboutsummaryrefslogtreecommitdiff
path: root/gdb/README
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-12-06 16:57:11 +0100
committerAlexandra Hájková <ahajkova@redhat.com>2023-12-13 10:46:44 +0100
commit8170efad364aa8e062cba3b722b81aca9eda8cf5 (patch)
treede4dfc67182ebf341a5be334c1c345379b5c2092 /gdb/README
parent7ae9ecfd80104a793ed1d836fd4dc0aa1a9c7832 (diff)
downloadgdb-8170efad364aa8e062cba3b722b81aca9eda8cf5.zip
gdb-8170efad364aa8e062cba3b722b81aca9eda8cf5.tar.gz
gdb-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/README')
0 files changed, 0 insertions, 0 deletions