11 ms·
I used to think GDB was a tool with the most broken interface I've ever seen, and which requires arcane commands to do the most trivial of debugging things. I
by yen223 9y ago
I used to think GDB was a tool with the most broken interface I've ever seen, and which requires arcane commands to do the most trivial of debugging things.
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.
- pjmlp 9y agoGDB already felt like that when we had C++ Builder, Visual C++, Zortech C++ visual debuggers on mid-90's versions of Mac and Windows. The only debuggers that could match them in usability and graphical debugging features were Motif based ones, being sold as a single product.
- exikyut 9y agoFrom a historical-software/UI perspective, I'm curious what that Motif software looks like, and how, er, findable it is. Studying old systems that have fallen by the wayside can often be instructive.
- pjmlp 9y agoStill found on Aix and HP-UX systems, which are the surviving ones. Solaris dropped it, and all other commercial big iron UNIXes are dead. You can get some screenshots here https://en.wikipedia.org/wiki/Common_Desktop_Environment https://en.wikipedia.org/wiki/Common_Desktop_Environment https://sourceforge.net/projects/cdesktopenv/ https://sourceforge.net/projects/cdesktopenv/
- exikyut 9y agoWoops, didn't notice this till now. I wasn't referring to Motif itself, rather the debugger programs. Contemporary UIs are always interesting to study! It's awesome that Motif and CDE are finally open source though.
- progman 9y agoThere are convenient graphical frontends for GDB. DDD for instance can create plots, diagrams, etc. https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/
- krona 9y agoFor what it's worth, VSCode and Visual Studio now have GDB integrations through its machine interface (MI). I use the VSCode one (part of the c/c++ extension) on a regular basis and while lacking functionality, it's very easy to use.
- pksadiq 9y agoIn GNU Emacs one can use gdb-many-windows in gdb debug mode to get the real power of gdb.
- pthreads 9y ago>I still do, but I used to too. I see what you did there. - Mitch Hedberg
- kakarot 9y agoIf you are curious as to why you're being downvoted, it's because this comment adds no substance and states something completely obvious. In other words, it was unnecessary. That kind of stuff is for reddit.
- pthreads 9y agoNo, I am not curious. I know exactly why I am being downvoted. 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.
- jwilk 9y agoThere was no humorous value in your comment. 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.
- dasil003 9y agoThe comment tells you to go look up Mitch Hedberg, that's much more useful than further explanation since explanation is the death of humor.
- nmg 9y agooff-topic.
- 9y ago
- davidreiss 9y ago> That early dig against Windows was particularly funny. There's no way I would pick that over Visual Studio's debugging tools. 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.
- pjmlp 9y agoWhat is at all elegant in UNIX style file systems?! Windows is as open as OS X, HP-UX, Aix, Solaris, OS/400, ....
- fest 9y agoI could agree with you on gdb's user interface. However, working on embedded hardware, plain gdb and it's architecture-specific forks|variants have been the least fiddly things to use. 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?)
- bramv 9y agoI stopped using the integrated debugging from an IDE because of the problems you described. Segger Ozone is doing a good job if you like a graphic interface. (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).
- fest 9y agoI've accustomed myself to openocd, gdb and some small custom scripts (e.g. interpreting fault registers) Hehe, the world really is that small :) Say hi to Mark if you meet him, I haven't seen him in ages.
- bennofs 9y agoCan you tell me some of the things that VS does much better? I've only ever used GDB, and I am kind of lost when trying to debug a binary on windows
- jussij 9y ago> I am kind of lost when trying to debug a binary on windows 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.
- jjoonathan 9y ago> a binary I'm not sure that there's a VS project and source code available for the binaries in question.
- to3m 9y agoWell if there isn't, you can start the EXE and do Debug|Attach from VS. Or (I think?), you can go to File|Open Solution, open the EXE directly, and let VS create a temporary solution for you that will let you run the EXE as a debuggee by pressing F5. 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=GreggMiskelly.MicrosoftChildProcessDebuggingPowerTool 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.)
- userbinator 9y agoI agree that gdb's syntax is ridiculous, having come from a background of DOS DEBUG and WinDbg, but what irritates me more are the implementations of certain functionality: - 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.
- bennofs 9y agoFirst of all, I agree! GDB without extensions is not that nice to use. But there exist several extensions (https://github.com/cyrus-and/gdb-dashboard https://github.com/cyrus-and/gdb-dashboard, https://github.com/hugsy/gef https://github.com/hugsy/gef, https://github.com/pwndbg/pwndbg https://github.com/pwndbg/pwndbg, https://github.com/longld/peda https://github.com/longld/peda, even though developed for it, these are not only useful for exploit dev!) that make it a lot better. > - 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 GDB feels quite similar to VIM to me: you have to spent some time to get used to it, it has some warts but it is very flexible and useful if you know it.
- jcelerier 9y agoyou have plenty of graphical frontends that bring it "down" to the ease of use of VS. I like QtCreator's gdb integration personnally.