From a869a48378d144f580e03fbd8bcea593e7afc195 Mon Sep 17 00:00:00 2001 From: Jacob Bower Date: Thu, 13 Jun 2024 18:08:05 -0700 Subject: [PATCH] Keep py-next/step working in gdb script even when in native code Summary: When I was testing this I only ever interrupted code directly in the interperter loop. It turns out that if we're in native code (called from the interpreter) we need to manually crank the handle a bit to get to a valid Python frame. Reviewed By: alexmalyshev Differential Revision: D57707850 fbshipit-source-id: a9990e0833240053c7fbddf223fa5b1ce369618e --- Tools/gdb/libpython.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Tools/gdb/libpython.py b/Tools/gdb/libpython.py index dbf15914d1b..18e84643200 100755 --- a/Tools/gdb/libpython.py +++ b/Tools/gdb/libpython.py @@ -2042,11 +2042,18 @@ def invoke(self, args, from_tty): global _PyRunningTargetFrameBackAddress frame = Frame.get_selected_python_frame() + # Aparently this frame is not actually a Python frame, so we need to + # walk to find it. This is based on the implementation around the + # PyUp/PyDown commands. + while frame: + if frame.is_python_frame(): + pyop_frame = frame.get_pyop() + if pyop_frame: + break + frame = frame.older() if not frame: print('Unable to locate python frame') return - - pyop_frame = frame.get_pyop() if not pyop_frame: print(UNABLE_READ_INFO_PYTHON_FRAME) return @@ -2066,4 +2073,3 @@ def invoke(self, args, from_tty): # gdb.execute('call (void*)dlopen("gdb_dbg.cpython-312-x86_64-linux-gnu.so", 2)') # PyRunningInit() -