11–20 of 25 posts
GDB can decode Python stack traces as Python code, as long as you have have python-gdb.py from the Python source distribution in the same place as your Python executable.
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.
GDB can decode Python stack traces as Python code, as long as you have have python-gdb.py from the Python source distribution in the same place as your Python executable.
> "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.
That reminds me of the time I debugged some code (also neural network) that was in both Java and C++ and I was able to attach both gdb and jdb to the same process but had to disable the segfault trap on gdb because the jvm segfaults all the time in normal operation.
Earlier quoted context omitted.
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.
Theres also Py Spy, a profiling tool that can generate flame charts containing a mix of python and C (or C++) calls. https://github.com/benfred/py-spy It's worked really well for my needs
GDB can decode Python stack traces as Python code, as long as you have have python-gdb.py from the Python source distribution in the same place as your Python executable.
GDB can decode Python stack traces as Python code, as long as you have have python-gdb.py from the Python source distribution in the same place as your Python executable.
(And no, I don't want it integrated into an IDE.)
That reminds me of the time I debugged some code (also neural network) that was in both Java and C++ and I was able to attach both gdb and jdb to the same process but had to disable the segfault trap on gdb because the jvm segfaults all the time in normal operation.
I dream of an IDE that is one-click, full-stack, local debug.
I dropped some ideas here: https://news.ycombinator.com/item?id=35650253
GDB can decode Python stack traces as Python code, as long as you have have python-gdb.py from the Python source distribution in the same place as your Python executable.
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 (whic…
FWIU Fedora GDB now optionally automatically installs debug syms; from attempting to debug TuxMath SDL with GDB before just installing the Flatpak.
https://developers.redhat.com/articles/2021/09/08/debugging-... (2021) describes more recent efforts to improve Python debugging with c extensions
That reminds me of the time I debugged some code (also neural network) that was in both Java and C++ and I was able to attach both gdb and jdb to the same process but had to disable the segfault trap on gdb because the jvm segfaults all the time in normal operation.
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?
https://www.lukeshu.com/blog/java-segfault-redux.html
Read the prior article for some context, too ..