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

71–77 of 77 posts

Re: Debugging with GDB

#71

Post by greglaw99 »

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 Code on Linux works really well and is increasingly popular, also a shout out for C-Lion. Eclipse is, umm, eclipsed by them both IMO.

My subjective opinion is that C-Lion is just a little bit more solid/complete, but Microsoft are investing heavily in VScode. It's great to see some serious competition by two well-resourced players working on this stuff.

Personally I'm always happiest with GDB tui. It's all the standard arguments of command-line vs GUI. When you know what you're doing CLI (with tab-complete) is just a faster way to accomplish the task, but when you're a noobie or an infrequent user the GUI wins because it's so much more discoverable.

Re: Debugging with GDB

#72

Post by mark_undoio »

jmclnx wrote: post #59
mark_undoio wrote: post #49

Earlier quoted context omitted.

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

Thanks! I also see there's a `/proc/sys/kernel/core_uses_pid` that will make you get `core.PID` files, without having to mess around with core patterns - seems useful.

Re: Debugging with GDB

#73

Post by westurner »

mark_undoio wrote: post #37
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 watch…

Time travel debugging https://en.wikipedia.org/wiki/Time_travel_debugging :

> Interactive debuggers include the ability to modify code and step forward based on updated information.[4] Reverse debugging tools allow users to step backwards in time through the steps that resulted in reaching a particular point in the program. Time traveling debuggers provide these features and also allow users to interact with the program, changing the history if desired, and watch how the program responds.[5]

https://github.com/rr-debugger/rr :

> System requirements: Linux kernel ≥ 3.11 is required (for PTRACE_SETSIGMASK).

> rr currently requires either:

> An Intel CPU with Nehalem (2010) or later microarchitecture. [OR] Certain AMD Zen or later processors

Is there an rr-like reverse time-travel debugging tool for ARM64/aarch64?

Are GUIs like Voltron and Ghidra helpful for gdb and/or rr-like traces?

Re: Debugging with GDB

#74

Post by khuey »

westurner wrote: post #73
mark_undoio wrote: post #37

Earlier quoted context omitted.

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

Time travel debugging https://en.wikipedia.org/wiki/Time_travel_debugging : > Interactive debuggers include the ability to modify code and step forward based on updated information.[4] Reverse debugging tools allow users to step backwards in time through the steps that resulted in reaching a particular point in the program. Time traveling debuggers provide these features and also allow users to interact with the prog…

rr works in principle on AArch64 though it requires an extremely recent CPU and the rest of system userspace to be compiled correctly.

Any gdb front end can probably be made to work with rr. Our current project is (shameless plug) https://pernos.co/ which provides a super-advanced GUI for working with (x86) rr traces.

Re: Debugging with GDB

#75

Post by westurner »

khuey wrote: post #74
westurner wrote: post #73

Earlier quoted context omitted.

Time travel debugging https://en.wikipedia.org/wiki/Time_travel_debugging : > Interactive debuggers include the ability to modify code and step forward based on updated information.[4] Reverse debugging tools allow users to step backwards in time through the steps that resulted in reaching a particular point in the program. Time traveling debuggers provide these features and also allow users to interact with the prog…

rr works in principle on AArch64 though it requires an extremely recent CPU and the rest of system userspace to be compiled correctly. Any gdb front end can probably be made to work with rr. Our current project is (shameless plug) https://pernos.co/ which provides a super-advanced GUI for working with (x86) rr traces.

"Support ARM" #1373 https://github.com/rr-debugger/rr/issues/1373

rr (software) https://en.wikipedia.org/wiki/Rr_(debugging)

Record and replay debugging https://en.wikipedia.org/wiki/Record_and_replay_debugging

/? site:github.com inurl:awesome https://www.google.com/search?q=site%3Agithub.com+inurl%3Aaw...

Re: Debugging with GDB

#76

Post by fuy »

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.

I'm far from expert in linux debugging, but I liked my experience with VS code gdb support - you can set breakpoints, stepping in/out works fine, you of course get nice code navigation and so on. My experience was mostly with Postgres code base, which is pure c, FWIW.

Re: Debugging with GDB

#77

Post by mark_undoio »

westurner wrote: post #73
mark_undoio wrote: post #37

Earlier quoted context omitted.

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

Time travel debugging https://en.wikipedia.org/wiki/Time_travel_debugging : > Interactive debuggers include the ability to modify code and step forward based on updated information.[4] Reverse debugging tools allow users to step backwards in time through the steps that resulted in reaching a particular point in the program. Time traveling debuggers provide these features and also allow users to interact with the prog…

> Is there an rr-like reverse time-travel debugging tool for ARM64/aarch64?

Aside from `khuey`'s comment (https://news.ycombinator.com/item?id=30779913) that `rr` can now work on ARM64, we at Undo (https://undo.io) have an ARM64 port under routine internal testing as we expect it to be important in the future.

GDB's built-in record/replay is also supposed to work on ARM64 - https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and...

Last I heard, on x86, the performance and memory overheads of that implementation were quite high but if it solves your problem maybe that's fine!

Post reply on HN