[HN Gopher] Debugging with GDB
___________________________________________________________________
Debugging with GDB
Author : MarcellusDrum
Score : 113 points
Date : 2022-03-01 10:25 UTC (12 hours ago)
(HTM) web link (felix-knorr.net)
(TXT) w3m dump (felix-knorr.net)
| easterncalculus wrote:
| GDB is great. I definitely recommend checking out watchpoints as
| well, a very useful tool for monitoring how a variable changes
| over time.
|
| GDB also has many good plugins - pwndbg has tons of features and
| UI improvements over stock GDB.
|
| https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.ht...
|
| https://github.com/pwndbg/pwndbg
| interroboink wrote:
| I like GDB, and use it a lot, but it always feels like it's
| teetering on the brink of being a pile of bugs. I manage to crash
| it semi-regularly, and there are dozens of little quality-of-life
| peccadilloes that make things annoying before working out a
| .gdbinit for yourself. It's like using Vim without a .vimrc (:
|
| I don't envy the maintainers' jobs, and I just gripe from the
| sidelines, but starting from scratch it's too bad it's such an
| intimidating experience, because it really is a great tool. And I
| say this as someone who has used MSVC's debugger (which I've
| often seen applauded as the best) for some decades, and I still
| prefer GDB now that I'm past the significant initial learning
| curve.
| ncmncm wrote:
| To me coming from GDB, MSVC 's debugger seems like nothing but
| a flashy toy. It cannot do _any_ of the things I need a
| debugger to do beyond stepping and setting breakpoints.
| sharikous wrote:
| gdb has been mauled by Apple in macOS in the name of security
|
| Maybe I am spoiled but I cannot bear the nagging about code-
| signing it yourself
| saagarjha wrote:
| GDB doesn't work anyways even after you codesign it because
| it's not actively maintained.
| Graziano_M wrote:
| Using vanilla GDB is painful. As a bit of a shameless plug I
| recommend you check out GEF[1]. It's a large python script that
| extends GDB to make it a lot better to use. Notably it shows a
| lot of the state automatically every time the inferior stops.
| It's oriented around reversing and exploit development, but it
| definitely doesn't have to be used that way.
|
| [1] https://github.com/hugsy/gef
| mortenlarsen wrote:
| It looks really awesome. Thanks.
|
| This anti-pattern is a bit of a red flag for me though:
| bash -c "$(curl -fsSL http://gef.blah.cat/sh)"
| NavinF wrote:
| I love that anti-pattern. It gets people thinking. It's not
| like anyone is gonna download that script, find out what the
| script downloads, and then read every line of the whole
| project and its dependencies to see if one of them installs a
| rootkit.
| [deleted]
| Graziano_M wrote:
| It certainly is. I don't install it that way, or recommend it
| be installed that way, but others do. You can take that up
| with the project owner :)
| stjohnswarts wrote:
| I sorta agree with you but only because it's an http site
| which allows easy MITM attacks . Otherwise, you're going to
| be downloading a shell script and executing it. You are
| trusting your system to a blind executable either way. Same
| with using pip, choco, rpm, brew, dnf, etc.
| dahfizz wrote:
| I've never understood why this gets so much hate.
|
| You are downloading and running their python script anyway.
| Why do you trust their software but not their install script?
|
| The fact that it is hosted on http is suboptimal, but it does
| redirect to an https github page in this case
| mortenlarsen wrote:
| For me it is because it normalizes bad practice. There is a
| reason we have packages and signatures.
|
| It is not as bad as: curl something | sh
|
| Where you can detect on the server side that the download
| goes into a pipe (due to buffering) and serve different
| versions of the file depending on if you are downloading it
| or executing it directly, but it is still bad practice.
| mistrial9 wrote:
| the difference includes -- a physical computer you use and
| care about, need to trust, with a lot of setup and your own
| efforts involved, may be a single-point endpoint with value
| and/or state, which is by definition vulnerable versus an
| ephemeral VM or Docker that is repeatedly created and
| destroyed in moments, has almost no lasting value since a
| new one is only a minute away, and has no personal value or
| customization.
| phendrenad2 wrote:
| After several decades of using GUI-based debugging in MSVC++ and
| CLion, I can't bring myself to regress back to command-line
| debugging. And sadly the GUI tools for GDB are abysmal.
|
| Recently I had to debug some bootloader code in QEMU, which
| provides a remote GDB port. I tried every GDB GUI and they all
| either (A) assumed that I would provide source code to the target
| code (it's a binary blob bootloader, which I don't have code for)
| or (B) flat out didn't work. I ended up using TUI mode, which has
| it's own problems (messes up my terminal when I
| disconnect/reconnect the GDB port)
| slavik81 wrote:
| I'd also recommend "Give me 15 minutes and I'll change your view
| of GDB" [1] by Greg Law at CppCon 2015. As someone who wasn't
| very familiar with GDB, I learned a lot from seeing it used by
| someone skilled. [1]: https://youtu.be/PorfLSr3DDI
| brtkdotse wrote:
| Having spent my entire career inside of Visual Studio (nee VS
| Code), this strikes me as a quaint relic from a time past.
|
| Can it be powerful? Probably. But the dev experience looks
| terrible.
| jcranberry wrote:
| sometimes gdb is what you got. cant always have visual studio
| when debugging something in a server.
| ncmncm wrote:
| VS debugger can do none of the things I look to a debugger to
| do.
|
| Dev experience is fixable in many ways, but wholesale lack of
| capability is not.
| ericbarrett wrote:
| Microsoft makes an excellent debugger. One advantage gdb has,
| though, is that you can attach it to almost any process over a
| terminal. Another (that I've seen used to great effect, but not
| since a long time ago) is that it's very straightforward to
| build up powerful libraries of debugging scripts--things like
| dumping or following custom data structures, which can be
| really useful for core file analysis and what not.
| 2c2c2c wrote:
| I haven't seen anyone demonstrate using gdb via CLI in the way
| you can show off using vim proficiently and have people say "I
| get it".
|
| In the reverse engineering space there's some folks that use gef.
| but maybe that's because linux folks dont have olydbg?
|
| would love to see a livestream of someone using gdb in the
| context of real world engineering. SHOW me the productivity wins
| here. every article and conference talk about gdb is just
| handwavey hypotheticals about what you could do, but in practice
| I just see people moving through basic debugging incredibly
| slowly
| IYasha wrote:
| The beginning was promising. I expected something for non-vim
| users. As a heavy VS user, I tried some Linux IDEs like KDevelop
| and Code::Blocks and, AFAIR, they integrated with GDB to resemble
| VS debugging process. For me personally, just pressing F5 (a hew
| hundreds of times a day) is a bit less cumbersome than running
| dgb program, start, etc. )
| stjohnswarts wrote:
| I think you mean that VS is emulating the Unix gdb GUI
| debugging process. No doubt some standards have cross
| pollinated.
| maCDzP wrote:
| GDB has a really nice TUI mode that helps a lot while debugging.
| interroboink wrote:
| Which, at least for me, needs an initial "C-x C-r" before it
| starts functioning via the normal "C-x C-a". I think there was
| some old bug about it, but I was never able to get to the
| bottom of it.
|
| But agreed, TUI mode is handy (:
| beembeem wrote:
| This! I recently discovered this as well and it makes gdb feel
| like a modern-day debugger like windbg.
|
| `C-x a` to toggle it on
|
| `C-l` to re-draw screen when stdout gets spit out and messes up
| TUI
|
| `C-p/n` for scrolling gdb history
|
| `up/down` for scrolling code
| limmeau wrote:
| I can really recommend debugging with command-line gdb (inside a
| text editor, of course; we're not barbarians). The transcript
| that lets you look back at the past of your debug session really
| adds a new dimension to the debug experience that a plain IDE
| integration just does not offer.
|
| (Time-travelling debuggers are OK, too, I guess)
| elteto wrote:
| What do you mean "inside a text editor"? What's the workflow
| that you describe like?
| mikepurvis wrote:
| I think it just means inside your editor's terminal, where
| there's usually some modest integrations like it detecting a
| source/line reference and either jumping you there or at
| least making it clickable.
|
| VSCode for sure does this.
| adhesive_wombat wrote:
| I cannot for the life of me get gdb to debug a remote in VS
| Code. The debugger runs, and breakpoints work and
| integrate, but the console is dead. '-exec print foo' does
| nothing.
| donio wrote:
| GUD in Emacs (M-x gdb) is another example of this. You are
| still interacting with the gdb cli but also get some source
| code buffer integration.
| limmeau wrote:
| gud-gdb in Emacs, yes.
| pjmlp wrote:
| Time travel to the UNIX world of early X Windows days.
|
| Now picture XEmacs and Emacs, running gdb as subprocess, with
| a little pointed finger showing the current line and a stop
| sign for breakpoints.
|
| The lower buffer shows the usual gdb repl and output.
| stjohnswarts wrote:
| Still available with DDD and various plugins to
| vim/emacs/vscode
| gumby wrote:
| Time travel to the late 70s and use the lisp machine
| debugger.
|
| I always felt the drive towards mouse-driven tools in the
| PARC world (InterLisp/SmallTalk/CedarMesa) was actually a
| regression because of the loss of history ("how the hell
| did I get here?")
| pjmlp wrote:
| They also had a proper REPL, and the reason I stay with
| Java and .NET ecosystems, is because they are the closest
| we can get back to the Xerox experience, after the UNIX
| divergence.
| pjmlp wrote:
| Just like I was doing with XEmacs in 1995...
|
| There is so much a modern IDE debugging session is capable of.
| azeirah wrote:
| What do you mean by transcript? I used gdb a while ago and it's
| mostly similar to a regular terminal application with readline.
| limmeau wrote:
| By transcript, I mean every command and every response in the
| debug session. Usually, in the beginning, I do not know yet
| what I'm looking for, and set breakpoints at points that may
| be interesting, and when I reach the breakpoints, I look at
| variables. Later, when I reach the point where things have
| gone wrong, I can look at variable values now, but also at
| the result of every previous query. This helps me answer
| questions like: was this object here already in that queue
| over there when the previous request came in?
|
| I can also attach the debug session to an issue in order for
| others or future me to understand what was happening then. In
| a purely GUI-driven debugger, I can copy&paste a stack trace
| of the final point, but the history is lost.
| loeg wrote:
| I've used scripts + logging in the past:
|
| https://sourceware.org/gdb/onlinedocs/gdb/Logging-
| Output.htm...
|
| Maybe that is what OP means by a transcript.
| ghoward wrote:
| I can't believe no one has mentioned `gdb-dashboard` [1] yet! I
| use it extensively. [2]
|
| Beyond that, I have recently learned how to write custom pretty
| printers for GDB. This saves a lot of screen space. I should
| probably update [2] soon with those new techniques.
|
| GDB is powerful, useful, and after getting my start in IDE
| debuggers, including Visual Studio, I struggle whenever I have to
| go back.
|
| [1]: https://github.com/cyrus-and/gdb-dashboard
|
| [2]: https://gavinhoward.com/2020/12/my-development-
| environment-a...
| shmerl wrote:
| cgdb can be helpful if you want a bit more visual experience:
| http://cgdb.github.io
| stjohnswarts wrote:
| Is this better or more featureful than just gdb --tui ?
| ncmncm wrote:
| It has the virtue of working. (Maybe I just didn't know about
| the needed initial C-x C-r?)
|
| There is a gap where GDB changed terminal interaction
| protocol and (on Debian) left cgdb behind, so I had to build
| my own copy of cgdb from source. Otherwise, smooth sailing.
___________________________________________________________________
(page generated 2022-03-01 23:01 UTC)