Movatterモバイル変換


[0]ホーム

URL:


ContentsMenuExpandLight modeDark modeAuto light/dark, in light modeAuto light/dark, in dark modeSkip to content
Python Developer's Guide
Logo
Python Developer's Guide
Back to top

GDB support

Page moved

Information on debugging CPython using GDB is now in the main Pythondocumentation, since it is relevant for C extension modules as well.Please read it first:Debugging C API extensions and CPython Internals with GDB

CPython tips

This document includes a few additional tips that are useful specifically fordebugging CPython internals.

Breaking at labels

You will most often set breakpoints at the start of functions, butthis approach is less helpful when debugging the runtime virtualmachine, since the main interpreter loop function,_PyEval_EvalFrameDefault, is well over 4,000 lines long as of Python 3.12.Fortunately, among themany ways to set breakpoints,you can break at C labels, such as those generated for computed gotos.If you are debugging an interpreter compiled with computed goto support(generally true, certainly when using GCC), each instruction will beprefaced with a label namedTARGET_<instruction>, for example,TARGET_LOAD_CONST. You can then set a breakpoint with a commandlike:

(gdb) break ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST

Add commands, save to a file, then reload in future sessions withoutworrying that the starting line number of individual instructionschange over time.

Saving and loading breakpoints

With extended exposure to particular parts of the Python runtime, youmight find it helpful to define a routine set of breakpoints andcommands to execute when they are hit.For convenience, save your breakpoints to a file and load them in futuresessions using thesavebreakpoints command:

(gdb) save breakpoints python.brk

You can edit the file to your heart’s content, then load it in a latersession:

(gdb) source python.brk
On this page

[8]ページ先頭

©2009-2025 Movatter.jp