From 066aab1ddd06adbf5c0c5436f9ddf5fdd3dcbbfd Mon Sep 17 00:00:00 2001 From: Skip Montanaro Date: Mon, 31 Oct 2022 12:32:56 -0500 Subject: [PATCH 1/6] a couple gdb tips --- advanced-tools/gdb.rst | 51 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/advanced-tools/gdb.rst b/advanced-tools/gdb.rst index df4d71e73..c9718d084 100644 --- a/advanced-tools/gdb.rst +++ b/advanced-tools/gdb.rst @@ -324,3 +324,54 @@ auto-load safe. One way to achieve this is to add a line like the following to ``~/.gdbinit`` (edit the specific list of paths as appropriate):: add-auto-load-safe-path ~/devel/py3k:~/devel/py32:~/devel/py27 + + +gdb Tips +======== + +Learning to use gdb effectively improves your chances of successfully +debugging problems with Python's internals. The tips here aren't yet +organized in any particular way. Over time, as the section grows, +hopefully useful organization will become apparent. + +Saving and Loading Breakpoints +------------------------------ + +With extended exposure to particular parts of the Python runtime, you +might find it helpful to define a routine set of breakpoints and +commands to execute when they are hit. (These might be appropriate to +a specific debugging/development task, or more generally useful.) To +make using multiple semi-static breakpoints easier to use, you can +save breakpoints to a file and load them in future sessions. For +example, you can save your current breakpoints to the file +``python.brk`` with this command:: + + save breakpoints python.brk + +You can edit the file to your heart's content, then load it in a later +session:: + + source python.brk + + +Breaking at Labels +------------------ + +You will most often set breakpoints at the start of functions, but +this approach is less helpful when debugging the runtime virtual +machine, since the main interpreter loop function, +``_PyEval_EvalFrameDefault``, is well over 4000 lines long as of 3.12. +Fortunately, among the `many 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 be +prefaced with a label named ``TARGET_``, e.g., +``TARGET_LOAD_CONST``. You can then set a breakpoint with a command +like:: + + break ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST + +Add commands, save to a file, then reload in future sessions without +worrying that the starting line number of individual instructions +change over time. From db0c0c9410fa20a7c18f1544968385a8190cfec5 Mon Sep 17 00:00:00 2001 From: Skip Montanaro Date: Mon, 31 Oct 2022 17:09:13 -0500 Subject: [PATCH 2/6] Apply suggestions from code review Incorporate feedback from @hugovk to the PR. Co-authored-by: Hugo van Kemenade --- advanced-tools/gdb.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/advanced-tools/gdb.rst b/advanced-tools/gdb.rst index c9718d084..0ea0a2bc0 100644 --- a/advanced-tools/gdb.rst +++ b/advanced-tools/gdb.rst @@ -326,10 +326,10 @@ to ``~/.gdbinit`` (edit the specific list of paths as appropriate):: add-auto-load-safe-path ~/devel/py3k:~/devel/py32:~/devel/py27 -gdb Tips +GDB Tips ======== -Learning to use gdb effectively improves your chances of successfully +Learning to use GDB effectively improves your chances of successfully debugging problems with Python's internals. The tips here aren't yet organized in any particular way. Over time, as the section grows, hopefully useful organization will become apparent. @@ -360,9 +360,9 @@ Breaking at Labels You will most often set breakpoints at the start of functions, but this approach is less helpful when debugging the runtime virtual machine, since the main interpreter loop function, -``_PyEval_EvalFrameDefault``, is well over 4000 lines long as of 3.12. +``_PyEval_EvalFrameDefault``, is well over 4,000 lines long as of Python 3.12. Fortunately, among the `many 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 be From bd8cb155b116646f7e7922127756e709f125891b Mon Sep 17 00:00:00 2001 From: Skip Montanaro Date: Wed, 2 Nov 2022 13:25:32 -0500 Subject: [PATCH 3/6] Apply suggestions from code review Co-authored-by: Erlend E. Aasland --- advanced-tools/gdb.rst | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/advanced-tools/gdb.rst b/advanced-tools/gdb.rst index 0ea0a2bc0..00687b393 100644 --- a/advanced-tools/gdb.rst +++ b/advanced-tools/gdb.rst @@ -326,32 +326,28 @@ to ``~/.gdbinit`` (edit the specific list of paths as appropriate):: add-auto-load-safe-path ~/devel/py3k:~/devel/py32:~/devel/py27 -GDB Tips +GDB tips ======== Learning to use GDB effectively improves your chances of successfully debugging problems with Python's internals. The tips here aren't yet -organized in any particular way. Over time, as the section grows, -hopefully useful organization will become apparent. +organized in any particular way. Saving and Loading Breakpoints ------------------------------ With extended exposure to particular parts of the Python runtime, you might find it helpful to define a routine set of breakpoints and -commands to execute when they are hit. (These might be appropriate to -a specific debugging/development task, or more generally useful.) To -make using multiple semi-static breakpoints easier to use, you can -save breakpoints to a file and load them in future sessions. For -example, you can save your current breakpoints to the file -``python.brk`` with this command:: +commands to execute when they are hit. +For convenience, save your breakpoints to a file and load them in future +sessions using the ``save breakpoints`` command:: - save breakpoints python.brk + (gdb) save breakpoints python.brk You can edit the file to your heart's content, then load it in a later session:: - source python.brk + (gdb) source python.brk Breaking at Labels @@ -363,14 +359,14 @@ machine, since the main interpreter loop function, ``_PyEval_EvalFrameDefault``, is well over 4,000 lines long as of Python 3.12. Fortunately, among the `many 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 +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 be prefaced with a label named ``TARGET_``, e.g., ``TARGET_LOAD_CONST``. You can then set a breakpoint with a command like:: - break ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST + (gdb) break ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST Add commands, save to a file, then reload in future sessions without worrying that the starting line number of individual instructions From f80fcd05bdaa0a782f4f72a1abb42e562baccac5 Mon Sep 17 00:00:00 2001 From: Skip Montanaro Date: Wed, 2 Nov 2022 13:28:12 -0500 Subject: [PATCH 4/6] Apply suggestions from code review Co-authored-by: Erlend E. Aasland --- advanced-tools/gdb.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/advanced-tools/gdb.rst b/advanced-tools/gdb.rst index 00687b393..abbc0a931 100644 --- a/advanced-tools/gdb.rst +++ b/advanced-tools/gdb.rst @@ -333,7 +333,7 @@ Learning to use GDB effectively improves your chances of successfully debugging problems with Python's internals. The tips here aren't yet organized in any particular way. -Saving and Loading Breakpoints +Saving and loading breakpoints ------------------------------ With extended exposure to particular parts of the Python runtime, you @@ -350,7 +350,7 @@ session:: (gdb) source python.brk -Breaking at Labels +Breaking at labels ------------------ You will most often set breakpoints at the start of functions, but From 9183dd9a82a3d13824e5b0395f4cfbbea9372ba3 Mon Sep 17 00:00:00 2001 From: Skip Montanaro Date: Wed, 2 Nov 2022 13:30:33 -0500 Subject: [PATCH 5/6] standardize other section headings --- advanced-tools/gdb.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/advanced-tools/gdb.rst b/advanced-tools/gdb.rst index abbc0a931..7d815a3f2 100644 --- a/advanced-tools/gdb.rst +++ b/advanced-tools/gdb.rst @@ -1,7 +1,7 @@ .. _gdb: =========== -GDB Support +GDB support =========== .. highlight:: none @@ -17,7 +17,7 @@ or what type or value has a given Python object represented by a standard limitation. -gdb 7 and later +GDB 7 and later =============== In gdb 7, support for `extending gdb with Python @@ -300,7 +300,7 @@ thread is doing at the Python level:: .. note:: This is only available for Python 2.7, 3.2 and higher. -gdb 6 and earlier +GDB 6 and earlier ================= The file at ``Misc/gdbinit`` contains a gdb configuration file which provides @@ -359,7 +359,7 @@ machine, since the main interpreter loop function, ``_PyEval_EvalFrameDefault``, is well over 4,000 lines long as of Python 3.12. Fortunately, among the `many ways to set breakpoints `_, -you can break at C labels, such as those generated for computed gotos. +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 be prefaced with a label named ``TARGET_``, e.g., From 747eb558348052cd80a81acbf651298daf2830b2 Mon Sep 17 00:00:00 2001 From: Skip Montanaro Date: Thu, 3 Nov 2022 18:47:59 -0500 Subject: [PATCH 6/6] Update advanced-tools/gdb.rst Co-authored-by: Ezio Melotti --- advanced-tools/gdb.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/advanced-tools/gdb.rst b/advanced-tools/gdb.rst index 7d815a3f2..1ce4049f4 100644 --- a/advanced-tools/gdb.rst +++ b/advanced-tools/gdb.rst @@ -330,8 +330,7 @@ GDB tips ======== Learning to use GDB effectively improves your chances of successfully -debugging problems with Python's internals. The tips here aren't yet -organized in any particular way. +debugging problems with Python's internals. Saving and loading breakpoints ------------------------------