Home >

GDB Deep Dive

Gillian Minnehan - Memfault- Watch Now - Duration: 32:26

GDB Deep Dive
Gillian Minnehan
GDB is a powerful tool to analyze and debug firmware. It enables developers to step through instructions, view disassembly, peer into registers, analyze back traces, and so much more to help debug. Without it, I cannot imagine developing firmware! There is a lot to unpack about how to use GDB effectively, so this talk will focus on a few key topics including a rundown of important GDB commands, the GDB Python API, options for visual debugging, and how GDB plays a role even after you ship IoT device firmware.
M↓ MARKDOWN HELP
italicssurround text with 
*asterisks*
boldsurround text with 
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with 
`backticks`
strikethroughsurround text with 
~~two tilde characters~~
quote
prefix with 
>
Chase.Weimer
Score: 0 | 5 months ago | no reply

This was such a great presentation. Thank you for sharing all of this!

srikrishnachaitanya
Score: 1 | 5 months ago | 1 reply

Fantastic talk Gillian! :-)
It was really informative.. I do have a question though.
How would you go around generating a coredump for a device on the field? lets say for a cortex-m processor.
Lets say we have some sort of flash memory, wouldnt a hardfault make it impossible to generate a coredump and write it to the flash memory (its a hardfault afterall ) ?
Say we are saving it in ram, then a reboot would essentially clear out any contents on power up, unless we do some sort of linker magic to preserve a section across reboots..
As i mentioned, it was a fantastic introduction to gdb..

GillianMSpeaker
Score: 0 | 5 months ago | 1 reply

Srikrishna, glad you enjoyed it. Thanks for jumping into the chat with a great question again. Saving a coredump will have to happen before the device reboots, so the state of the system can be saved. Therefore, collecting data for a coredump will need to happen as part of the handling of a fault, so you would need to write your own fault handler to do this collection. You can take a look at our fault handler here. Notice that we call memfault_platform_coredump_get_regions() in this handler, which is a function that will collect data for the coredump. As far as where to put it once it has been collected, yes, flash is one option. You could also store it in the "noinit" region of RAM, which persists across boots. You can take a look at our RAM-backed coredump here which does exactly that! Note however that space is more limited when using that region so only a few items could be collected like the active stack, PC, and LR. But, it is typically faster to get up and running with when first trying out coredump collection.

srikrishnachaitanya
Score: 0 | 5 months ago | no reply

Thank you for the response Gillian! :-)
Oh thats a nice way of storing the coredumps... the noinit section... but I would imagine for flash storage it has to happen after a reboot and recover the data from the noinit section and then dump it into flash memory before rest of the system boots up..
Nevertheless, very interesting and helpful! Thank you again Gillian.