Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Give me 15 minutes and I'll change your view of GDB (2015) [video]

youtube.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#81

Post by kakarot »

SimonPStevens wrote: post #65
pmoriarty wrote: post #60

Earlier quoted context omitted.

This is another example where HN needs tags. 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 down…

I really like this idea. [meta], [general-agreement], [non-contributing]

Until people spam the non-contributing tag on posts they don't like in an attempt to silence them, and companies abuse it to try and cover up posts that badmouth them, giving mods a constant headache.

[non-contributing]

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#82

Post by ksk »

corndoge wrote: post #45
jussij wrote: post #40

Earlier quoted context omitted.

> 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 Debu…

While a simple series of steps it's still pretty complex compares to the equivalent in gdb: $ gdb ./binary (gdb) break file.c:line (gdb) run I think this is merely a disguised version of the "CLIs are too hard" argument...

Calling it "CLIs are hard" is trivializing it but anyway, it depends on what your common case is. For C/C++, CLIs slow me down tremendously. In an IDE, You don't need to type a single command to view program state (automatic + local + thread storage), call stacks, memory usage, CPU Usage, Heap activity, unpacked C++ containers, GPU state, etc. But this is not even that impressive TBH. FME Windows in general is better at debug symbol management than Linux especially when it comes to shipped binaries. The post[0] sums it up nicely:

"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...

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#83

Post by vidarh »

roca wrote: post #80
vidarh wrote: post #54

As I've written on this subject before, I think current debuggers largely miss the point, though gdb misses the point in a whole different league. 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 t…

You should try using rr. The combination of reverse execution and hardware data watchpoints enables new, much more direct, debugging strategies to answer the kinds of questions you posed.

rr doesn't work on my CPU yet. Or at least not without building from git, and that fails due to some compilation problem or other. I haven't had time to try much more than that, but from what I can tell from the docs it does seem better though I think at unnecessarily high cost. I already have code that make Valgrind fall over because its state exhausts my memory, so I'l be interested in seeing how rr fares there.

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#84

Post by ithkuil »

bennofs wrote: post #75
saaadhu wrote: post #56

Earlier quoted context omitted.

"b 0x12345" will place a line breakpoint at line number 0x12345 of the current source file. The "nonsensical" extra asterisk is used to tell gdb that you want an address breakpoint instead.

Oh! That makes sense, thank you. It only raises the question though, does anyone really use hexadecimal line numbers? :)

Just a guess: if you have an expression language that lexes numbers in a few bases, then when parsing some commands you no longer know which base the number token was, all you know is that you got a number, and in case of the break command you interpret that as a line number unless prefixed with a * token

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#85

Post by bennofs »

ksk wrote: post #82
corndoge wrote: post #45

Earlier quoted context omitted.

While a simple series of steps it's still pretty complex compares to the equivalent in gdb: $ gdb ./binary (gdb) break file.c:line (gdb) run I think this is merely a disguised version of the "CLIs are too hard" argument...

Calling it "CLIs are hard" is trivializing it but anyway, it depends on what your common case is. For C/C++, CLIs slow me down tremendously. In an IDE, You don't need to type a single command to view program state (automatic + local + thread storage), call stacks, memory usage, CPU Usage, Heap activity, unpacked C++ containers, GPU state, etc. But this is not even that impressive TBH. FME Windows in general is better…

The symbol thing sounds useful and is something I cannot comment on, since most often I either debug open source programs that I run myself (so I have the binary with compiled with debug symbols) or there is no source at all for the binary (and so no symbols). But, most of the other things you listed are, IMO, quite easy with GDB:

> view program state

in my experience, your often only interested in a few variables. then, you just run

    display var
once for each variable and GDB will show the value of var on every break. There is also `info locals` to show a local variables, and I am pretty sure that you can set it up to run on every break with some simple config (there's probably an extension pack that does it)

> 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.

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#86

Post by pjmlp »

progman wrote: post #8
yen223 wrote: post #5

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.

There are convenient graphical frontends for GDB. DDD for instance can create plots, diagrams, etc. https://www.gnu.org/software/ddd/

DDD was always for me the only sane way to use GDB. Until I got hold of it, I was mostly using it from Emacs.

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#87

Post by pjmlp »

davidreiss wrote: post #16
yen223 wrote: post #5

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.

> 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.

What is at all elegant in UNIX style file systems?!

Windows is as open as OS X, HP-UX, Aix, Solaris, OS/400, ....

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#88

Post by pjmlp »

dman wrote: post #69
ustokes wrote: post #37

Agree. I started embedded coding on Linux + Qt-Creator. I have everything working, compiling and running on my ARM and AVR chips, but Debuging jsut does nto work. Just can't find any proper info on how to integrate GDB into Qt-Creator and be able to just Debug like in Visual Studio. If this is not possible, that this endeed is very stupid, starting/stopping servers on a remote target and the rest...

I don't think the situation is likely to improve much unless as a profession we become open to paying for quality tools.

We used to be open to paying for quality tools, then the FOSS generation took over, killing the business of selling tools to single developers.

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.

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#89

Post by btschaegg »

bennofs wrote: post #52
userbinator wrote: post #48

Earlier quoted context omitted.

I 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 b…

First 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/hugsy/gef , https://github.com/pwndbg/pwndbg , 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…

That's about the same vibe I got from GDB so far. I don't use it all to often, so I'm certainly not that "effective" in it, but I still get my debugging done. And yes, it is a bit arcane.

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.

Re: Give me 15 minutes and I'll change your view of GDB (2015) [video]

#90

Post by exikyut »

pjmlp wrote: post #7
yen223 wrote: post #5

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.

GDB 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.

From 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.

Post reply on HN