Debugging a Mixed Python and C Language Stack (opens in new tab)

Funny, I was going to post this, but the horse's mouth is even better ;)

GDB does so much cool. It just sucks that it's missing a high quality front-end. I know there are a bunch out there, but they all seem pretty janky and get confused a lot; I just want a really serious group of people (some Red Hat people for example) to make a high quality native debugging app which properly speaks the GDB protocol and handles all the edge cases.

(And no, I don't want it integrated into an IDE.)

What I would love is also to be able to set python breakpoints from gdb. And integration with rr, so I could reverse-continue to said breakpoints. And ponies.

Wow, that's pretty amazing. I wonder how it's implemented, and if there are any tutorials on implementing something similar, for programming language designers/creators.

This has been packaged as Tools/gdb/libpython.py lately.

From https://github.com/jupyterlab/debugger/issues/284 en ENH: Mixed Python/C debugging (GDB,) #284

> "Users can do [mixed mode] debugging with GDB (and/or other debuggers) and log the session in a notebook; in particular in order to teach.

> Your question is specifically about IDEs with support for mixed-mode debugging (with gdb), so I went looking for an answer:

> https://wiki.python.org/moin/DebuggingWithGdb (which is not responsive and almost unreadable on a mobile device) links to https://fedoraproject.org/wiki/Features/EasierPythonDebuggin... , which mentions the py-list, py-up and py-down, py-bt, py-print, and py-locals GDB commands that are also described in * https://devguide.python.org/gdb/ *

> https://wiki.python.org/moin/PythonDebuggingTools Ctrl-F "gdb" mentions: DDD, pyclewn (vim), trepan3k (which is gdb-like and supports breaking at c-line and also handles bytecode disassembly)

> Apparently, GHIDRA does not have a debugger but there is a plugin for following along with gdb in ghidra called https://github.com/Comsecuris/gdbghidra [...] https://github.com/Comsecuris/gdbghidra/blob/master/data/gdb... (zero dependencies)

> https://reverseengineering.stackexchange.com/questions/1392/... lists a number of GUIs for GDB; including voltronnn:

>> There's Voltron, which is an extensible Python debugger UI that supports LLDB, GDB, VDB, and WinDbg/CDB (via PyKD) and runs on macOS, Linux and Windows. For the first three it supports x86, x86_64, and arm with even arm64 support for lldb while adding even powerpc support for gdb. https://github.com/snare/voltron

> "The GDB Python API" https://developers.redhat.com/blog/2017/11/10/gdb-python-api... describes the GDB Python API.

> https://pythonextensionpatterns.readthedocs.io/en/latest/deb... may be helpful [for writing-a-c-function-to-call-any-python-unit-test]

> The GDB Python API docs: https://sourceware.org/gdb/onlinedocs/gdb/Python-API.html

> The devguide gdb page may be the place to list IDEs with support for mixed-mode debugging of Python and C/C++/Cython specifically with gdb?

These days, we have CFFI and Apache Arrow for C+Python etc.

As a C++ developer, I'm struggling to understand how and why segfaults would ever be part of normal operation. In my mental model, the presence of a segfault means that a program has gone so far off the expected path that no guarantees can be made about its state whatsoever, so the only safe thing to do is to let the program crash. Is there a reason why the JVM regularly segfaults?

Which reminds me that with IntelliJ you can get a really nice combo for debugging Java/C/C++ code: https://youtu.be/8Cjeq4l5COU

I predominantly develop in Python but somewhat frequently peer into the C++ and CUDA underlying Pytorch. I am not a competent C or C++ programmer but often am able to debug and fix bugs that originate in the lower levels of the stack. That ability developed just through exposure and focused prodding when I found issues, but I don't think it has much relation or translates to being a professional coder in C/C++/CUDA. Coding and debugging are different skill sets IMO.