Adding Coredumps to Your Debugging Toolkit
summary
Coredumps capture concrete RAM regions—kernel structures, per-thread stacks, peripheral memory—and are converted from the Zephyr logging output into a coredump.bin that the Zephyr GDB server loads alongside the elf so GDB (use the -py build) can inspect state. The demo loads the dump, lands at calculate_transformed_reading, and Python extensions (notably GDB bundle) parse GPIO and print thread states. A practical failure is that the flash back end is not ISR-safe and deadlocks with assertions; proposed fixes include an application-overridable linker region and a flash-simulation backend.
AI-written summary · about
chapters (23)
- 0:00Core dumps in Zephyr
- 2:05Core dumps for debugging
- 3:30Core dump components
- 4:54Triggering core dumps
- 6:18Core dump architecture
- 7:24Device-specific data capture
- 8:48Log-based core dump output
- 9:30Logs to binary format
- 10:30GDB server protocol
- 11:13GDB client extensions
- 12:58GDB setup for core dumps
- 13:18Demo: log to binary core dump
- 14:03Starting GDB server
- 15:07Loading core dump in GDB
- 15:52Analyzing core dump
- 16:34Debugging with GDB extensions
- 17:57Future core dump improvements
- 18:18Fixing flash backend ISR issues
- 19:03Customizing memory regions
- 19:46Encouraging core dump submissions
- 20:07Flash simulation for testing
- 20:49Resources
- 21:52Acknowledgments
related talks
15mGive me 15 minutes & I'll change your view of GDB
59m“GDB - A Lot More Than You Knew"
29mLiberating the Debugging Experience with the GDB Python API
52mGetting the Most Out of GDB
27mZephyr and You: A Developer Environment for Newcomers
01h 02mTime Travel Debugging
50mPost-Mortem Debugging in Node.js
01h 01m“Time Travel Debugging..."