- 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
(gdb) run
"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."
[0]https://randomascii.wordpress.com/2013/02/20/symbols-on-linu...
> view program state
in my experience, your often only interested in a few variables. then, you just run
display var
> 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]
[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.
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.