You're reading from Linux Kernel Debugging Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules

Product type Paperback

Published in Aug 2022

Publisher Packt

ISBN-13 9781801075039

Length 638 pages

Edition 1st Edition

Tools

Linux

Concepts

System Administration

Author (1):

Kaiwan N. Billimoria

View More author details

Table of Contents (17) Chapters

Preface

1. Part 1: A General Introduction and Approaches to Kernel Debugging

2. Chapter 1: A General Introduction to Debugging Software FREE CHAPTER

3. Chapter 2: Approaches to Kernel Debugging

4. Part 2: Kernel and Driver Debugging Tools and Techniques

5. Chapter 3: Debug via Instrumentation – printk and Friends

6. Chapter 4: Debug via Instrumentation – Kprobes

7. Chapter 5: Debugging Kernel Memory Issues – Part 1

8. Chapter 6: Debugging Kernel Memory Issues – Part 2

9. Chapter 7: Oops! Interpreting the Kernel Bug Diagnostic

10. Chapter 8: Lock Debugging

11. Part 3: Additional Kernel Debugging Tools and Techniques

12. Chapter 9: Tracing the Kernel Flow

13. Chapter 10: Kernel Panic, Lockups, and Hangs

14. Chapter 11: Using Kernel GDB (KGDB)

15. Chapter 12: A Few More Kernel Debugging Approaches

16. Other Books You May Enjoy

An introduction to kernel code coverage tools and testing frameworks

Code coverage is tooling that can identify which lines of code get executed during a run and which lines of code don't. Tools such as GNU coverage (gcov), and kcov and frontend tools such as lcov can be very valuable in gleaning this key information.

Why is code coverage important?

Here are a few typical reasons why you should (I'd go so far as to say must) perform code coverage:

Debugging: To help identify code paths that are never executed (error paths are pretty typical), thereby making it clear that you need test cases for them (to then catch bugs that lurk in such regions).
Testing/QA: Identify test cases that work and, more to the point, ones that need to be written in order to cover lines of code that never get executed, as, after all, 100% code coverage is the objective!
They can help with (minimal) kernel configuration. Seeing that certain code paths are never taken perhaps...