3 ms·

Just wanted to mention gdbgui, a new front end to gdb that I developed which is similar to Chrome's debugger, has a gdb terminal which you can fall back to if y

Just wanted to mention gdbgui, a new front end to gdb that I developed which is similar to Chrome's debugger, has a gdb terminal which you can fall back to if you want to run gdb commands, and data structure/value plotting and visualizations similar to ddd. https://github.com/cs01/gdbgui https://github.com/cs01/gdbgui

cheez 9y ago
This looks great! Did you know that you can also use Chrome's debugger to debug Node? I wonder how difficult it would be to use Chrome's debugger as a front end for gdb.
- grassfedcode 9y ago
  Never tried, but pygdbmi would probably get you halfway there. It uses python to parse structured data (key/value pairs) from gdb output. Gdbgui uses it on its backend. (Disclaimer: I am the developer) https://github.com/cs01/pygdbmi https://github.com/cs01/pygdbmi Also for golang: https://github.com/cyrus-and/gdb https://github.com/cyrus-and/gdb
Asooka 9y ago
Awesome! Does it support gdb startup scripts? I.e. the gdb -x option which instructs gdb to read and execute commands from a file and then drops you off in the normal prompt. I regularly use that, because it lets me keep and organise startup options for the programs I work on. I really don't want to have to type all the "set environment" &c stuff that's necessary for the programs I want to debug. Does it (can it) work with the gdb pretty-print API? On the console I can define pretty printers for my data types using python, so I can examine them easily. I almost never want to explore a struct by expanding its fields, I just have a bunch of python scripts that extract a summary of what's important. E.g. for a 3-component vector type I don't need or want something like { x = ... y = ... z = ... } I just have a pretty-printer that spits out "MY::Vector(x, y, z)". Similarly for a whole bunch of other classes. I especially don't want to look at STL objects by field, that's just insane. Honestly, after a couple of years of using GDB, the console interface isn't really a problem for me, and I've become quite attached to the many customisation and automation features it offers. While the commands and syntax are all kinds of gnarly, I don't think I can ever go back to a debugger where I have to do everything manually via direct control. Better, faster, more intuitive direct control is always a good thing, but I don't want it if it's at the expense of the programmability of the debugger.

cheez 9y ago

This looks great! Did you know that you can also use Chrome's debugger to debug Node? I wonder how difficult it would be to use Chrome's debugger as a front end for gdb.

grassfedcode 9y ago
Never tried, but pygdbmi would probably get you halfway there. It uses python to parse structured data (key/value pairs) from gdb output. Gdbgui uses it on its backend. (Disclaimer: I am the developer) https://github.com/cs01/pygdbmi https://github.com/cs01/pygdbmi Also for golang: https://github.com/cyrus-and/gdb https://github.com/cyrus-and/gdb

Asooka 9y ago

Awesome! Does it support gdb startup scripts? I.e. the gdb -x option which instructs gdb to read and execute commands from a file and then drops you off in the normal prompt. I regularly use that, because it lets me keep and organise startup options for the programs I work on. I really don't want to have to type all the "set environment" &c stuff that's necessary for the programs I want to debug. Does it (can it) work with the gdb pretty-print API? On the console I can define pretty printers for my data types using python, so I can examine them easily. I almost never want to explore a struct by expanding its fields, I just have a bunch of python scripts that extract a summary of what's important. E.g. for a 3-component vector type I don't need or want something like { x = ... y = ... z = ... } I just have a pretty-printer that spits out "MY::Vector(x, y, z)". Similarly for a whole bunch of other classes. I especially don't want to look at STL objects by field, that's just insane. Honestly, after a couple of years of using GDB, the console interface isn't really a problem for me, and I've become quite attached to the many customisation and automation features it offers. While the commands and syntax are all kinds of gnarly, I don't think I can ever go back to a debugger where I have to do everything manually via direct control. Better, faster, more intuitive direct control is always a good thing, but I don't want it if it's at the expense of the programmability of the debugger.