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 Oops on an ARM Linux system and using netconsole

To get the most out of this section, I'd definitely recommend you be at least a little conversant with the processor ABI conventions (especially stuff such as function calls, parameter passing, and return values) for the processor your code's running upon. So, here, it's for the ARM32. Again, do review the basics that we covered in Chapter 4, Debug via Instrumentation – Kprobes, in the section, Understanding the basics of the Application Binary Interface (ABI).

Here, our test environment is a Raspberry Pi 0W running Raspbian 10 (Buster) with the standard 5.10.17+ kernel. This popular prototyping (and product) board has the Broadcom BCM2835 System on Chip (SoC), which internally sports a single ARM32 CPU core for this board.

We cross-compile and run our usual test case on the device: our oops_tryv2 module case 3 (passing the bug_in_workq=yes parameter). It does cause an Oops, of course, but the bug was severe...