Gregory's ServerHey Lina!
I was just wondering, since you 'put compiling with debug' here, what debug toolkits do you use for kernel/driver work? Is GDB still cool or in the era of Rust, is it all compiler checks?
Sincerely,
GDB's biggest fan
|
Top-level
Hey Lina! I was just wondering, since you 'put compiling with debug' here, what debug toolkits do you use for kernel/driver work? Is GDB still cool or in the era of Rust, is it all compiler checks? Sincerely, 2 comments
|
@mbeavitt @cyan I usually use debug prints if I'm tracking down misbehavior, both in the kernel and userspace, since debuggers like gdb aren't very useful when you don't know what triggers the problem to begin with ^^;; (this is also why both our kernel and userland driver have lots and lots of debug prints you can toggle on).
If it's an assert/panic then I'll use gdb to get a stack trace (userland) or the m1n1 hypervisor (kernel land) and try to figure out how it got there.
If it's a GPU firmware crash then the m1n1 hypervisor to inspect firmware/GPU/memory state.
If it looks like memory corruption then valgrind/ASAN (userland) or kASAN (kernel) to hopefully catch it.
It's pretty rare that I get to do something "deep" with gdb (like dynamic breakpoints and scripting) but very rarely it does happen!
@mbeavitt @cyan I usually use debug prints if I'm tracking down misbehavior, both in the kernel and userspace, since debuggers like gdb aren't very useful when you don't know what triggers the problem to begin with ^^;; (this is also why both our kernel and userland driver have lots and lots of debug prints you can toggle on).