Live data from Hacker News

Beej's Quick Guide to GDB (2009)

beej.us

11–20 of 29 posts

Re: Beej's Quick Guide to GDB (2009)

#11
post #9

Remote debugging and especially the extended-remote mode are worth knowing. That is usually my default workflow. The debugger (client and frontend) run on my desktop box while the app is running under gdbserver on an ARM board on the network. The other day I was debugging a Windows game on my Linux laptop, editing in vim, compiling with x86_64-w64-mingw-clang and gdbserver running on my desktop PC. Not the most comfo…

As someone who's spent a good amount of time in both GDB and Visual Studio don't be so quick to knock the dev tools on Windows, they're really quite good.

Re: Beej's Quick Guide to GDB (2009)

#12
post #8
post #2

Beej’s guides are great! He does a fantastic job of describing concepts and showing implementations. I also recommend his networking guide: https://beej.us/guide/bgnet/html/single/bgnet.html

I'm a huge fan of his guides for their readability and straightforward delivery. I'm always on the lookout for more authors like him - have you come across any similar authors?

Recently came across this nice guide on Git pull request workflow: https://github.com/susam/gitpr

All the important stuff is in the first 4 pages. I have the PDF version on my desktop. Also printed pages 3 and 4 and stuck it to my cubicle wall.

Re: Beej's Quick Guide to GDB (2009)

#15
I'll preface this by saying that I don't have that much C or C++ experience. Now on to the topic of debugging em:

I'd suggest trying out lldb [0] as an alternative to gdb. In general it has more sensible commands [1] and it can be scripted with python.

If you're willing to pay, CLion [2] is amazing and it includes an interactive debugger [3] which, IMO, completely blows away these CLI tools.

[0] https://lldb.llvm.org/index.html

[1] https://lldb.llvm.org/lldb-gdb.html

[2] https://www.jetbrains.com/clion/

[3] https://www.youtube.com/watch?v=wUZyoAnPdCY

Re: Beej's Quick Guide to GDB (2009)

#16
post #9

Remote debugging and especially the extended-remote mode are worth knowing. That is usually my default workflow. The debugger (client and frontend) run on my desktop box while the app is running under gdbserver on an ARM board on the network. The other day I was debugging a Windows game on my Linux laptop, editing in vim, compiling with x86_64-w64-mingw-clang and gdbserver running on my desktop PC. Not the most comfo…

As someone who's spent a good amount of time in both GDB and Visual Studio don't be so quick to knock the dev tools on Windows, they're really quite good.

Windows is a platform I very seldom use. I had a few hour debugging job, so not worth installing the dev tools. I could just use the tools I always do.

Re: Beej's Quick Guide to GDB (2009)

#17

I'll preface this by saying that I don't have that much C or C++ experience. Now on to the topic of debugging em: I'd suggest trying out lldb [0] as an alternative to gdb. In general it has more sensible commands [1] and it can be scripted with python. If you're willing to pay, CLion [2] is amazing and it includes an interactive debugger [3] which, IMO, completely blows away these CLI tools. [0] https://lldb.llvm.org…

In general it has more sensible commands

I completely disagree (and I don't think GDB's command set is all that great either); the page you linked shows that LLDB's commands are even longer, which is extremely annoying when you're forced to use it for any length of time. Getting a good standard hexdump out of either is a pain too, and LLDB has this ridiculously stupid arbitrary limit of 1024 bytes to display each command (which can be overridden by specifying an additional option each time, but... why!?)

I think "more sensible commands" would be what WinDbg and SoftICE have. Short and unobtrusive.

Re: Beej's Quick Guide to GDB (2009)

#18

I'll preface this by saying that I don't have that much C or C++ experience. Now on to the topic of debugging em: I'd suggest trying out lldb [0] as an alternative to gdb. In general it has more sensible commands [1] and it can be scripted with python. If you're willing to pay, CLion [2] is amazing and it includes an interactive debugger [3] which, IMO, completely blows away these CLI tools. [0] https://lldb.llvm.org…

How is CLion for embedded work these days? If I have, say, an ARM GDB server running, can I use that with CLion's debugger?

Re: Beej's Quick Guide to GDB (2009)

#19

I'll preface this by saying that I don't have that much C or C++ experience. Now on to the topic of debugging em: I'd suggest trying out lldb [0] as an alternative to gdb. In general it has more sensible commands [1] and it can be scripted with python. If you're willing to pay, CLion [2] is amazing and it includes an interactive debugger [3] which, IMO, completely blows away these CLI tools. [0] https://lldb.llvm.org…

gdb has been scriptable with python since 7.0 https://sourceware.org/gdb/onlinedocs/gdb/Python.html#Python

Re: Beej's Quick Guide to GDB (2009)

#20
post #6

I never knew gdb had a tui mode. It is not even specified in the man page as an option.

The manual is worth a read. This is a software (as gcc) in which the "man" page or the information displayed with "--help" is not near the bunch of things there are described in the complete documentation.

Yes. The GNU manuals tend to be excellent sources. GNU Make's is particularly great. https://www.gnu.org/software/make/manual/make.html
Post reply on HN