Home > On-Demand Archives > Talks >

Tools and Techniques to Debug an Embedded Linux System

Sergio Prado - Watch Now - Duration: 58:53

Tools and Techniques to Debug an Embedded Linux System
Sergio Prado

Summary: In this talk, we will learn how to use different tools and techniques to debug an embedded Linux system.

Description: There are several tools and techniques to debug an embedded Linux system that can be applied in both user space and kernel space. Depending on the problem, you may need different tools like addr2line for crash dump analysis, GDB for interactive debugging, ftrace for kernel tracing, valgring to catch memory-related issues, gprof for application profiling, etc! In this hands-on oriented talk, we will learn how these and many other tools and techniques can be used when debugging an embedded Linux system.

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
>

Carlos.Amaya
Score: 1 | 2 years ago | no reply

Thank you very much Sergio, great presentation!

phfbertoleti
Score: 1 | 2 years ago | 1 reply

Sergio, absolutely fantastic presentation! Thanks for sharing such an amazing content!

I've a question for you: to get kernel logs when we're developing a product, it's usual to configure a serial console for kernel and check the messages sent there (as I believe you've done when checking kernel crash in USB sub-system) during developing and testing phases. However, sometimes we're in a situation where there isn't a "free" uart for this (like debugging a product which a bug has been discovered in field operation, for example). In these cases, what's the best way to get kernel crash logs? Could you please share some good practices in this situation?

Thanks in advance.

sergio_pradoSpeaker
Score: 0 | 2 years ago | no reply

Hi phfbertoleti! I am glad you enjoyed it!

About your question, you have a few options:

  1. You could redirect kernel logs (including kernel oops messages) to some persistent storage that you could retrieve later. Usually, log daemons like journald or rsyslogd are able to do that.
  2. You could use the kernel pstore framework. This framework enables you to store kernel logs (including crashes) in a separated region of memory that you could retrieve later (after a soft reset for example).

Hope that helps.

Thanks!

glennk
Score: 1 | 2 years ago | 1 reply

This was a fantastic talk, you are spot on debugging is not given anywhere near enough attention which it certainly deserves! I also loved "THE SIX STAGES OF DEBUGGING", classic!

sergio_pradoSpeaker
Score: 0 | 2 years ago | no reply

I am glad you liked it!

LeeT1
Score: 1 | 2 years ago | 1 reply

Will the video be available for download? You covered a lot more information during the debugging exercises than are covered in the slides.

Stephane.Boucher
Score: 1 | 2 years ago | no reply

If you mean the video of the presentation, they cannot be downloaded. But they can be watched at will on the website.

jgaitan
Score: 1 | 2 years ago | 1 reply

Awesome session, extremely informative!

sergio_pradoSpeaker
Score: 0 | 2 years ago | no reply

Thanks @jgaitan! I am glad you enjoyed it!

OUR SPONSORS