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

71–80 of 95 posts

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

#71

Post by pbhjpbhj »

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

Looks like you need to talk to nocman https://news.ycombinator.com/item?id=14999140 or jcelerier https://news.ycombinator.com/item?id=14999140?

Assuming http://doc.qt.io/qtcreator/creator-debugging.html (which someone else noted) didn't help.

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

#72

Post by Asooka »

grassfedcode wrote: post #26

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

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.

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

#73

Post by Asooka »

abbeyj wrote: post #58

If don't like the Ctrl-X,A shortcut to get into TUI mode there is a command line option (--tui) to get GDB to start up in TUI mode. I find that a lot easier to remember. 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…

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

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

#74

Post by fest »

bramv wrote: post #67
fest wrote: post #18

Earlier quoted context omitted.

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

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

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

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

#75

Post by bennofs »

saaadhu wrote: post #56
bennofs wrote: post #52

Earlier quoted context omitted.

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…

"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? :)

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

#76

Post by xixor2 »

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

> While a simple series of steps it's still pretty complex compares to the equivalent in gdb:

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.

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

#77

Post by slrz »

userbinator wrote: post #48
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.

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…

GDB is used in lots of places, often times called programmatically. You can't just change long-standing behaviour and get away with it. This is not a web framework.

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.

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

#78

Post by Graziano_M »

jdright wrote: post #47

Some other very nice: https://github.com/snare/voltron https://github.com/cyrus-and/gdb-dashboard 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.

GEF as well: https://github.com/hugsy/gef

Voltron adds awesome views, GEF adds a lot of handy functionality. I use both (often together)

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

#79

Post by frankzinger »

zython wrote: post #4

The TUI in gdb is a great way to get started with gdb. Instead of writing your own hooks and commands you can visually step through the program and source code ( if you have debug symbols enabled) I think that more people should know about this feature.

Absolutely. Many of the comments here deride the default gdb interface but the TUI is orders of magnitude more usable and I only learned of it recently. (I much prefer it over Emacs' interface, for example, something another commenter recommended.) And in single-key mode it's even better.

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

#80

Post by roca »

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.
Post reply on HN