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

51–60 of 77 posts

Re: Debugging with GDB

#51

Post by begriffs »

jmclnx wrote: post #38
0xbadcafebee wrote: post #14

Earlier quoted context omitted.

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.

> OpenBSD, where you get core files by default

By this, are you referring to the behavior: "By default, this memory image is written to a file named programname.core in the working directory, provided the terminated process had write permission in the directory[...]" (from https://man.openbsd.org/core.5) ?

Also, do you know if there's a way to obtain a core file from a running process on OpenBSD? I don't see a port of gcore, and (e)gdb on OpenBSD doesn't support the generate-core-file command (it says, "Can't create a corefile").

Re: Debugging with GDB

#52

Post by nyanpasu64 »

gnud wrote: post #36
nyanpasu64 wrote: post #30

Earlier quoted context omitted.

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

How do I use these pretty printers outside of KDevelop? When I source that file from my global .gdbinit, I get the classic Python relative import error:

  ModuleNotFoundError: No module named 'qt'
Changing KDevelop's gdbinit to `from .qt import register_qt_printers` results in:

  ImportError: attempted relative import with no known parent package
The problem is that sourcing KDevelop's gdbinit doesn't let Python import packages relative to that file. Is there an alternative way to do this?

Re: Debugging with GDB

#53

Post by lanstin »

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.

yeah, c with emacs and gdb works like a dream. Truly integrated deveopment experience. Scary langiage but great tooling. and valgrind works with them also, so your violating line pops up in the editor when it does a UMR or other memory error.

Re: Debugging with GDB

#54

Post by usefulcat »

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've used gdb exclusively for over 10 years now (been working on Linux, worked on Windows prior to that). gdb may well be more powerful overall, but for common use cases (setting breakpoints, stepping in/out, examining values) I still miss the Visual Studio debugger. It's the only thing from Windows I miss.

Re: Debugging with GDB

#56

Post by edgyquant »

usefulcat wrote: post #54
edgyquant wrote: post #25

Earlier quoted context omitted.

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've used gdb exclusively for over 10 years now (been working on Linux, worked on Windows prior to that). gdb may well be more powerful overall, but for common use cases (setting breakpoints, stepping in/out, examining values) I still miss the Visual Studio debugger. It's the only thing from Windows I miss.

Interesting. Got any tips (or articles) for someone who is beginner level with debuggers (I wrote some C almost a decade ago that got my feet wet, but I’ve forgotten most of it by now.)

Re: Debugging with GDB

#57

Post by kmarc »

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

to my surprise, vim has built-in support (:help termdebug) for gdb. It's not as chiselled as some GUI debuggers but still usable and makes it (visually) easier to debug in terminal.

Accidently I also moved my mouse cursor over a variable while stopped at a breakpoint, in a terminal, over ssh, and there is a hovering balloon popping up with the current state of that variable. Mind blown.

Re: Debugging with GDB

#58

Post by kmarc »

billfruit wrote: post #13

On Emacs the GUD major mode, makes using GDB from the GUI quite convenient. Does VIM has anything similar?

Yes. https://news.ycombinator.com/item?id=30760084

There is also vimspector, which is more advanced, a full blown debugging solution, using LSP and its lesser known cousin, the debugger adapter protocol. However, its quite hard to set up and success isn't guaranteed.

Re: Debugging with GDB

#59

Post by jmclnx »

mark_undoio wrote: post #49
jmclnx wrote: post #38

Earlier quoted context omitted.

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

What did you figure out as a solution? I've previously configured `/proc/sys/kernel/core_pattern` to generate core dumps by default (and not pipe them to a core dump collection program, which may be useful for error reporting but is rarely what I want). There's also `gcore` for doing on-demand core dumps. I wish it were possible to configure core dump behaviour per-process (or something similar).

This is what I did:

ulimit -S -c unlimited

sudo sysctl -w kernel.core_pattern=core

took me a while to figure this out, HTH

Re: Debugging with GDB

#60

Post by binarycrusader »

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/

For Windows folks, WinDbg also supports Time-Travel Debugging:

https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

Post reply on HN