I still do, but I used to too.
That early dig against Windows was particularly funny. There's no way I would pick that over Visual Studio's debugging tools.
- No way to get a 16-column (bytes+ASCII) standard hexdump. This is functionality that even the most basic debugger should have, yet it's missing from gdb.
- "disassemble" command is next to useless.
- If you write "b 0x12345" intending to set a breakpoint at address 0x12345, it doesn't work. An unnecessary and nonsensical extra asterisk is needed (which makes it look like it's retrieving 4/8 bytes from 0x12345, and using that as the address of the breakpoint.)
- Starting gdb with a binary and passing arguments to it --- you'd expect it to be smart enough to realise that anything after the executable name should be the arguments to the debuggee and not the debugger, but it isnt.
I don't use gdb often, but when I do, it's usually the option of last resort.
> - No way to get a 16-column (bytes+ASCII) standard hexdump. This is functionality that even the most basic debugger should have, yet it's missing from gdb.
This should be quite easy to implement as a small python snippet that you put in your ~/.gdbinit. Granted, this should be builtin functionality, but it also shows how extensible GDB can be.
> - If you write "b 0x12345" intending to set a breakpoint at address 0x12345, it doesn't work. An unnecessary and nonsensical extra asterisk is needed (which makes it look like it's retrieving 4/8 bytes from 0x12345, and using that as the address of the breakpoint.)
Agreed, I never understood why that was necessary. It is really annoying. Perhaps someone wanted to avoid a conflict if you had a symbol named "0x12345"? (can you even do that?)
> - Starting gdb with a binary and passing arguments to it --- you'd expect it to be smart enough to realise that anything after the executable name should be the arguments to the debuggee and not the debugger, but it isnt.
I recently learned that gdb has a neat option called --args, that does exactly this:
gdb --args program arg1 arg2
However, on the topic of picking this over the VS debugger: The lack of arcane configuration, socket permissions and usage steps required to get it running on remote machines is what would make me pick it over VS nearly all the time. I haven't yet gotten to try the VS2017 one, but its predecessors were abysmal in that regard.
Tellingly, GDB's simplicity in that regard - which is the same as far as many other UNIXy tools go - comes from the approach of "if you have an SSH connection, you're good to go", which is something that is lacking in almost any Microsoft tool.
So additional positional arguments on the gdb command line will always be interpreted as core files or PIDs instead of being passed through to the inferior program (unless using --args).
Similar things apply to other complaints.
The most recent examples I've stumbled upon were System Workbench for STM32 and Atollic Studio debugging relatively recent STM32F7 series. When the debugging from IDE doesn't work, it's very hard to see where the problem is (is the hardware interface service started? with the correct parameters? does it have access to hardware USB device? did it even succeed flashing the firmware?)
(BTW nice to see you here again. I think we met at some point playing with a laser cutter next to your old office in Riga).
Hehe, the world really is that small :) Say hi to Mark if you meet him, I haven't seen him in ages.
The only debuggers that could match them in usability and graphical debugging features were Motif based ones, being sold as a single product.
Studying old systems that have fallen by the wayside can often be instructive.
You can get some screenshots here
It's awesome that Motif and CDE are finally open source though.
When I want to debug a program using the Visual Studio IDE I do the following:
1. Start the IDE and open the solution file.
2. Make sure the Debug Build option is selected.
3. Open a given file in the solution that I want to debug.
4. Select a line in that file and use the Debug, Toggle Breakpoint menu to set a breakpoint.
5. Run the debugger using the Debug, Start Debugging menu and wait for the breakpoint to be hit.
6. When that break point is hit just use the debugger to examine the state of the program.
$ gdb ./binary
(gdb) break file.c:line
"I can take a crash dump file from a customer running an arbitrary version of our games, running on an arbitrary version of Windows, load it into the debugger and have all of the symbols automatically show up. I don’t need to know or care what version of the game or what service pack of Windows the customer was running, and I don’t need to think about package names or new repositories. The symbols and binaries Just. Show. Up."
> view program state
in my experience, your often only interested in a few variables. then, you just run
> call stacks
almost every enhancement plugin for GDB in python that I know of does this (GEF, voltron, ...)
> unpacked C++ containers
I am pretty sure GDB pretty-prints C++ containers?
This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either.
Surely then, the difference between whats possible, and whats easy/default out of the box isn't simply "CLIs are hard" ! :)
Anyway it seems like we'd agree on most things, so nothing really left to discuss.
Oh come on. If you're developing with visual studio, you've already got it open and have been compiling with it.
Debugging in VS is literally click the mouse where you want to stop, F5, full call stack/local variables there in front of you.
Given the list above, if you reproduce a similar list for gdb it is also pretty tedious: run a terminal emulator, spawn a new shell, cd to the directory you want to work in, compile the program with gcc with the appropriate flags, run gdb with the appropriate arguments.
Where VS shines for me is inspecting the state of datastructures. As long as you don't need to do any complex search on them, or programmatically walk a graph of them.
I'm not sure that there's a VS project and source code available for the binaries in question.
If you're debugging an EXE without source because you're writing a plugin or addon for it as a DLL, and you want todebug that DLL, you can specify the EXE in question as the EXE to run when you start debugging as part of the properties for the project for the DL in question. Visual Studio will spot when your DLL loads, load the debug info for it, and activate any breakpoints and so on. Works well.
(If your addon runs as a child process, you need the Child Process Debugging tool. Transformative. Get it here: https://marketplace.visualstudio.com/items?itemName=GreggMis...)
When you don't have source code, VS is not the best environment ever - it's oriented very much towards worknig with C/C++/etc., and there's a few options you have to play with to get it to show you disassembly and so on. But it's adequate. (One thing I like about it very much is that the step commands are the same whether you're stepping through source code or whether you're stepping in the disassembly window. I'll put up with quite a lot in exchange for that.)
Also, if you add in edit-and-continue so you can modify the code and have it automatically recompiled and keep debugging it, that adds value too.
I assume that various editor adaptations for vim/emacs etc means that you get almost all the IDE experience with gdb as well (symbol navigation, syntax highlight etc) and at that point there is of course little difference between one IDE and another.
Throw in the Sysinternals suite and hopefully powershell continues to improve and you have a very nice debugging/sys admin/etc toolset.
I just wished windows had the elegance of the unix-style file system and was as open as linux/bsd/etc.
Windows is as open as OS X, HP-UX, Aix, Solaris, OS/400, ....
I see what you did there.
- Mitch Hedberg
In other words, it was unnecessary. That kind of stuff is for reddit.
HN'ers sometimes need to lighten up a bit. A little humor among thousands of serious comments (many not useful) is not going to bring down HN and it is incorrect to assume it doesn't add any substance. My comment was not crass, sarcastic, degrading or mean. It was appreciating the commenter's sense of humor in a harmless way.
People who are familiar with Mitch Hedberg's work don't need any help in recognizing the quote.
For people who haven't heard about Mitch Hedberg, your comment doesn't make any sense without further research.
To me it sounded like you're bragging that you understood the reference.
The original humorous comment could have been tagged "humor" and the parent reply could have been tagged "meta", and an HN reader could have their client filter posts based on their preferences: if they want to see humor or meta posts, they could have them -- if they don't they won't and their feed will be leaner and less annoying to them, and there'll be less need to downvote "off-topic" posts.
Then everyone would be happy.
[meta], [general-agreement], [non-contributing]
I had never heard of Mitch Hedberg, and therefore did not get the quote, and now I have enjoyed several clips of his comedy routines.
I agree with the pthreads, many people on HN are far too quick to hit the "that stuff is for reddit" button, and could definitely lighten up a bit.
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 = ...
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.
Also for golang: https://github.com/cyrus-and/gdb
Now I'm using an awesome GDB init file to construct a convenient debugging interface. It's an open source project and you won't regret it:
There is also a browser-based frontend for GDB:
If you want to try more, search the keyword GDB on GitHub and sort by stars, then you will find many GDB enhancement tools.
I particularly like Voltro's view modularity and backends support. But dashboard is a really nice throwback (SoftICE) with its theme and sensible default layout.
Voltron adds awesome views, GEF adds a lot of handy functionality. I use both (often together)
I think that more people should know about this feature.
Then again, I also use Vim as an IDE. But so do a lot of folks here.
Note, that you will need version from git, but anyway, new release of radare2 will be ready in less than a couple weeks.
It also doesn't help that I've never gotten gdbserver to actually work reliably on my embedded Linux targets (which, to be fair, are not Cortex-A/Apple/Qualcomm chips, so probably being tested by ~nobody). I'd understand if some operations aren't supported due to missing debug hardware or emulation magic, but stuff tends to just start mysteriously breaking (e.g. not stopping on breakpoints, hanging when trying to print memory, crashing on resume/step, etc.).
I think cgdb (https://cgdb.github.io/) is even better than TUI mode though. Some nice things that it has that TUI mode doesn't:
- Colorization of the source code window
- The terminal display doesn't get confused when the debugged program prints to stdout
- You can still use the up and down arrow keys for moving through your command history and don't have to resort to Ctrl-P and Ctrl-N. Scrolling the source code window also uses the up and down arrow keys but you have to switch the "focus" to the source code window first.
Minor correction, that's the same as gdb tui. Use ^X,O to select which window has focus and you can use up and down arrow to go through your command history. The rest is definitely better in cgdb.
What I want from a debugger is 99% of the time met by gdb by running a program and running a backtrace and inspecting a few variables. Where gdb falls flat by default is in making me type in commands to get a register view, backtrace, disassembly of the current area, and the current stackframe.
Most other debuggers do ok there. But even with gdb it's trivial to define a few macros to make that part easy.
Where every debugger I've used falls flat is that for most harder problems, their functionality seems focused on heaping on functionality to let me do the job the debugger should have, instead of actually doing the things that would really save me time.
I've increasingly instead turned to valgrind as my first choice, for the simple reason that a huge portion of the problems I deal with are low level (e.g. debugging my compiler, which involves debugging things like why my code generation doesn't correctly initialise a value on the stack. But this is the same problem I generally would like to be able to debug in higher level languages:
Program crashes. Which value caused the crash, or caused the exception to be thrown? When was that value set? Where? What was the code paths that led to that value being set? Which variables contributed to it being set to that value?
Fully automating this in the general case is not possible (it devolves to the halting problem if you don't put the debugged program in a "black box"), but making it easy for a human to guide it there should be the priority for a debugger.
Being able to get a quick view, see that "huh, that value shouldn't be there", be able to tell the debugger "identify when that variable will change and re-run", and work your way back that way, would solve the vast majority of the tough debugging sessions I've had.
Note that the above is not the same as just setting watch-points by tracing and checking. Handling of watches is usually crude in most debuggers. What I'd like is something similar to Valgrind - to do this well the debugger needs to at least analyse the code and intelligently pare down what it watches, and ideally dynamically translate the code into something sufficiently instrumented to let it run fast. For most debugging sessions where I've tried watches, I've had to give up because of how slow they can be, but if the issue is something valgrind can catch, it finds it fast.
Support for replays might be an improvement, but it's still about providing tools for us to do the debuggers job instead of semi-automating vital functionality.
Assuming http://doc.qt.io/qtcreator/creator-debugging.html (which someone else noted) didn't help.
Nowadays the only way to make money selling developer tools is to sell them to enterprises, the only ones that value developer time vs money spent on tooling.