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

Debugging with GDB

sourceware.org

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Debugging with GDB

#31

Post by mark_undoio »

jraph wrote: post #12
jokoon wrote: post #8

How difficult is it to setup an editor like sublime text with gdb? I'm curious if it can be an alternative to visual studio, meaning a window showing the stack, locals, watch, etc?

I don't know if it is possible in Sublime text (I never tried it), but there are several GUI frontend to GDB, including Nemiver and KDbg, as well as some IDEs allowing to use GDB to debug, like KDevelop and Eclipse. I'd expect Emacs to have some GDB integration as well.

Emacs's GDB integration is probably my favourite (aside from using GDB directly):

https://www.gnu.org/software/emacs/manual/html_node/emacs/GD...

It gives you an IDE-like interface but supports easy access to the command line (as you'd expect, given Emacs's focus on text-based UX). Unlike (some of) the full IDEs it doesn't require you to be fully committed to a particular way of doing things (build systems, projects, etc).

I understand that VScode and CLion are also fairly lightweight IDEs and have GDB integration too, though ISTR VScode doesn't have watchpoint support yet. You can always type directly into the console, though.

Re: Debugging with GDB

#32

Post by Decabytes »

edgyquant wrote: post #25
Decabytes wrote: post #11

I learned a lot of debugging using GDB from Greg Laws CPPCon talk https://www.youtube.com/watch?v=-n9Fkq1e6sg . With that being said, one of the things I've heard is that debugging on Linux is a poorer experience than it is on Windows. I believe that RAD Game Tools tried to create a debugger for Linux that was better, but the project failed for some reason. I hope with the increased interest in Linux, GDB or another…

Interesting, the last time GDB hit the front page the consensus seemed to be it was far ahead of all the competition. Having never seriously used a debugger it seems like it’s an opinion to me.

I found the link http://www.radgametools.com/debug.htm. Though it looks like the project has been abandoned https://github.com/ValveSoftware/vogl Taken from their FAQ on that page about "Why make a new source-level debugger?"

> To put it bluntly, debugging on Linux is just really bad. We believe it is the biggest roadblock to great software for that platform. Don't get us wrong - debugging on Windows isn't great either. But the standard Visual Studio debugger is still much better than anything on Linux.

> So we want to make Linux debugging as good as Windows debugging. And then we want to make both better - much better. There are so many better debugging tools that we can imagine having, and yet even today's best debuggers provide barely any functionality that wasn't in debuggers twenty years ago.

> Also, we think there's a lot of value in having one great debugger that you can use on every platform. RAD develops software for roughly 18 platforms now. A big part of the friction of a new platform is dealing with different toolsets.

> Compilers, linkers and runtimes are all hard to deal with, certainly, but you typically finish setting those up in a few days or weeks. The debuggers, on the other hand, are tools you have to use every day for as long as you develop on that platform!

I guess it's just really hard to do this stuff

Re: Debugging with GDB

#33

Post by zoomablemind »

mixedmath wrote: post #20
bee_rider wrote: post #6

I generally stick pretty close to the classic "old but still good" tools, but GDB is something I really could not get a handle on (probably because it isn't a daily-use tool for me).

What do you use for debugging instead?

Print statements indeed. That's when the source project is at your fingertips. Otherwise, it's more about collecting and figuring out the conflicting state, than locating the actual problem. So saving a core/logs is paramount.

Re: Debugging with GDB

#34

Post by GuB-42 »

jraph wrote: post #12
jokoon wrote: post #8

How difficult is it to setup an editor like sublime text with gdb? I'm curious if it can be an alternative to visual studio, meaning a window showing the stack, locals, watch, etc?

I don't know if it is possible in Sublime text (I never tried it), but there are several GUI frontend to GDB, including Nemiver and KDbg, as well as some IDEs allowing to use GDB to debug, like KDevelop and Eclipse. I'd expect Emacs to have some GDB integration as well.

It is possible, and it kinds of work but I didn't manage to get productive with it. It is far from Visual Studio or even QtCreator. I went back to the command line.

Emacs has GDB integration too, but it has been a long time since I used Emacs. Again, I don't remember being very successful with it and went back to the command line.

Edit: By Visual Studio, I mean the real one, not VS Code. VS Code is on the same level as Sublime Text, maybe a little bit better integrated. Among the different environments I have used, I consider Visual Studio to have the best C/C++ debugger, by far.

Re: Debugging with GDB

#35

Post by mark_undoio »

bee_rider wrote: post #21
mixedmath wrote: post #20

Earlier quoted context omitted.

What do you use for debugging instead?

Print statements, haha. My code is for linear algebra stuff, so it is pretty much a straight shot through/filling in some RCI loop most of the time, I usually just have to find which OpenMP or MPI barrier is misbehaving.

Print statements are really really good for debugging because they give you a timeline of "things that happened that I was interested in".

It's like using Google Maps to see the general shape of a landscape. A debugger is generally more like Google Streetview - you get strictly more detail and it makes some problems way easier to solve. It's just not always the easiest way to get an overview.

With that in mind, though, GDB's "Dynamic Printf" is pretty cool: https://sourceware.org/gdb/onlinedocs/gdb/Dynamic-Printf.htm...

You basically configure GDB to add printfs to the program you're debugging, without having to rebuild it. You just run under GDB and the prints will run. As a bonus, you can also interact using normal debugging commands too.

Re: Debugging with GDB

#36

Post by gnud »

nyanpasu64 wrote: post #30
ho_schi wrote: post #2

Took me some time to get familiar with it but GDB is well documented and fulfills its duty. It looks ancient but it is powerful. Do not underestimate the power of the print command! And the advanced stuff like revers-debugging, multi-threading (all-stop mode - which is the default - and the non-stop mode), binary manipulation (yep, it is possible), and remote debugging. Nowadays accompanied by stuff like debuginfod.…

> Do not underestimate the power of the print command! Still waiting for it to print the contents of a QList or QString, or pull actual data in cases where I see .

As I understand it, you can plug in the qt pretty printers from https://invent.kde.org/kdevelop/kdevelop/-/tree/master/plugi...

Re: Debugging with GDB

#37

Post by mark_undoio »

buserror wrote: post #4

One absolutely essential companion to gdb is 'rr' [0], it's a 'post mortem' debugger, but unlike a core file, you can replay the action, in reverse if necessary. You can reverse-cont, reverse-step create watchpoints, run forward again etc etc. It's absolutely amazing! [0]: https://rr-project.org/

The best thing about time travel debugging is that you effectively get an instruction-perfect reproducer for the problem you're looking at.

Even if the problem only occurs one time in a thousand, if you have recorded it then you can review it in arbitrary detail as many times as you need. You can even send the recording to another developer for their feedback.

Probably the second best thing about time travel is watchpoints[0] + reverse-continue[1] - combining these two features, you can answer "why is that value there?" incredibly quickly.

Reverse execution + watchpoints is so powerful it can speed up the diagnosis of memory corruptions, race conditions, algorithmic bugs, etc from days/weeks to hours.

[0] https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.ht...

[1] https://sourceware.org/gdb/onlinedocs/gdb/Reverse-Execution.... - GDB has an implementation of reverse debugging but larger projects like `rr` (https://rr-project.org/) or `udb` (https://undo.io/solutions/products/udb/ - which, disclaimer, I work on) exist to do this with higher performance on complex, real-world programs.

(edit: format links better)

Re: Debugging with GDB

#38

Post by jmclnx »

0xbadcafebee wrote: post #14
bee_rider wrote: post #6

I generally stick pretty close to the classic "old but still good" tools, but GDB is something I really could not get a handle on (probably because it isn't a daily-use tool for me).

Even if the rest of GDB remains a mystery to you, you can learn the two simplest and most useful functions: 1) how to create a backtrace, and 2) how to create a core dump. That way you can always send a bug report with lots of detail to somebody else for analysis.

> 2) how to create a core dump

This is a PITA under Linux, I figured this out but nor happy I had to look.

I wish Linux was like OpenBSD, where you get core files by default. This give me yet another reason to switch to OpenBSD, I only wish some other issues I am having with OpenBSD could get solved.

Re: Debugging with GDB

#39

Post by mark_undoio »

havkom wrote: post #22

Have not used gdb for a while but I think a good gdb tip is that you can evaluate functions with the print p command: > p myfunction()

Getting more advanced, you can generally do this anywhere GDB will accept a value. Which means you can do things like:

> break my_file.c:123 if my_function() == 0x5

i.e. please stop at `my_file.c` line 123 but when `my_function()` is returning the value 0x5. GDB will handle calling the function and checking its value every time you get there.

Re: Debugging with GDB

#40

Post by mark_undoio »

ho_schi wrote: post #2

Took me some time to get familiar with it but GDB is well documented and fulfills its duty. It looks ancient but it is powerful. Do not underestimate the power of the print command! And the advanced stuff like revers-debugging, multi-threading (all-stop mode - which is the default - and the non-stop mode), binary manipulation (yep, it is possible), and remote debugging. Nowadays accompanied by stuff like debuginfod.…

On a similar note - add `set history save on` to your `~/.gdbinit` and retain command history between runs of GDB (just like with your shell).

https://sourceware.org/gdb/onlinedocs/gdb/Command-History.ht...

Post reply on HN