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

61–70 of 77 posts

Re: Debugging with GDB

#61

Post by jmclnx »

begriffs wrote: post #51
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.

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

Yes,

kill -ABRT pid

should do it

Re: Debugging with GDB

#62

Post by gnud »

nyanpasu64 wrote: post #52
gnud wrote: post #36

Earlier quoted context omitted.

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

I've never actually used these, I just knew they existed. I found them via DuckDuckGo, in the github repository of qBittorrent. They have a step-by-step guide for using them, without mentioning kdevelop:

https://github.com/qbittorrent/qBittorrent/wiki/Setup-GDB-wi...

Re: Debugging with GDB

#64

Post by usefulcat »

edgyquant wrote: post #56
usefulcat wrote: post #54

Earlier quoted context omitted.

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

The single biggest thing I’d recommend is using the -tui option. I wish I’d noticed that one sooner.

Re: Debugging with GDB

#66

Post by israrkhan »

billfruit wrote: post #13

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

if you are using neovim, nvim-dap has support for debug adapters, which includes gdb in addition to several other languages (python, nodejs, java etc). Here [1] are available debug adapters.

It is noteable that nvim-dap just provides support for debug adapters, if you are looking for nice UI, there are other plugins such as nvim-dap-ui [2].

In vim land, there is vimspector. I have not used vimspector myself, but from what I hear, it is slower than nvim-dap.

[1] https://microsoft.github.io/debug-adapter-protocol/implement...

[2] https://github.com/rcarriga/nvim-dap-ui

Re: Debugging with GDB

#67

Post by begriffs »

jmclnx wrote: post #61
begriffs wrote: post #51

Earlier quoted context omitted.

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

Yes, kill -ABRT pid should do it

Good idea to just abort it. :)

However, I tried your suggestion from another terminal, and gdb appears to shield the program somehow. What ended up working is running "signal SIGABRT" from within gdb.

One thing that's still lacking is gcore's ability to take a snapshot of the core without killing the program. "Unlike after a crash, after gcore finishes its job the program remains running without any change." https://www.man7.org/linux/man-pages/man1/gcore.1.html

Re: Debugging with GDB

#68

Post by pjmlp »

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.

Mostly because the ones that praise GDB know very little about the competition.

Re: Debugging with GDB

#69

Post by pjmlp »

Alekhine wrote: post #16

Are there any easier to use C debuggers than GDB? All I really need to do is watch my variables change with each line.

Visual Studio, C++ Builder and XCode.

But if you really only need to watch variables any GUI frontend to gdb like QtCreator or DDD will do.

Re: Debugging with GDB

#70

Post by adaszko »

kmarc wrote: post #58
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.

This article goes into a little more detail which may be useful: https://www.dannyadam.com/blog/2019/05/debugging-in-vim/
Post reply on HN