Linux kernel Debugging Guide __linux

Some preface

Preface by the author

Where does the knowledge come from?

Why this document is written

Why assembly-level debugging is required

The first part: basic knowledge * * *

Master: The pitfalls of the kernel world

The trap of source code reading

Traps for code debugging

The trap of understanding the principle

Setting up a debugging environment

Selection and installation of distributions

Installing the cross-compilation tool

Use of the Bin tool set

Use of QEMU

Principle and fabrication of initrd.img

Establishment of x86 virtual debugging environment

Establishment of ARM virtual debugging environment

Establishment of the debugging environment of ARM Development Board

GDB Basics

Basic commands

GDB's GUI

GDB Tips

GDB macros

Compilation Foundation--x86 article

User manual

AT&T Assembly format

inline assembly

Mutual invocation of assembly and C functions

Call chain formation and parameter passing

The assembly explanation of C difficulty

Impact of the optimization level

Compilation Foundation--arm article

User manual

Call chain formation and parameter passing

Source Browsing Tool

Call Graph Generation Tool

Find + grep

Wine + SI

Global

Source-navigator

Vim + cscope/ctags

Kscope

Lxr

The characteristics of Si and gdb

Call chain, call Tree, and call graph

Ideal Call chain

function pointer calls

Hierarchy of Call chains

Non-ideal call chain

Call Tree and call graph

Through the blind Zone

Through the blind area of GDB

Blind spot through the Cross indexing tool

Engineering methods

Bugs and OOPS

Part II: CORE ANALYSIS * * *

Debugging related subsystems

KGDB Source Analysis

SysRq

Oprofile

Kprobes

Drive analysis

Load module symbol

Analysis of SEQ_FILE.C

Analysis of MODULE.C

Interrupt handling Process

S3C24XX Analysis of Memory initialization

Virtual address space

User-level Observation window

Interacting, analyzing from the kernel layer

Understanding Device Models

Object-oriented implementation

Layering of device models

Perimeter support mechanism

File system

Part III: OTHER TOOLS * * *

Strace

Ltrace

SystemTap

Memwatch

Yamd

Magic SYSRQ

Appendix: Community Communication related

Patch Submit related Documents

Patch Production and submission demonstration

Git uses

Appendix: Kernel Reference book articles

Private Memo

Linux kernel Debugging Guide
There are a lot of fish in the sea, and we need a hook.
This document is freely written, modified and expanded by everyone, Sniper is responsible for maintenance. Refer to foreign articles to indicate the author and the place. All commands in this document are operated under Ubuntu/debian. The selected kernel source code starts with the latest kernel version –2.6.26 when the document is written, and changes the new version as Linux is updated. So the contents of the document may not be consistent. I believe everyone has the ability to overcome this problem.

The character icon in this document appears normal in the Linux environment, showing subtle confusion under Windows.

The only updated URL of this document is: Http://wiki.zh-kernel.org/sniper reprint please keep this website.

Any suggestions please send an email: s3c24xx@gmail.com

Any questions please go to the mailing list to ask questions: Http://zh-kernel.org/mailman/listinfo/linux-kernel

Some preface
Preface by the author
It's been a while for a man to beat this article silently. In the process, received no praise, nor received any board bricks, without any feedback. Just beat it, fix it. But I never doubted the value of this document because I was the beneficiary of this document. Here to give it "selfless" dedication out, but for a certain kind of fellow people perseverance assiduously pursued the "virtue" and "sympathy", your pain I expressed empathy, your confusion I would like to share. Someone must be able to benefit from a document that has made me contented. In fact, writing this document is not a chore, but the word is a feeling of hair, do not vomit unpleasant results. The sentence here is a record of my lessons and experience.

When it comes to the debugger, there are two very different views. One kind, is the super Jie Ba author, he thinks "the procedure is not to write out, the good procedure is definitely debugging out". For this point of view, although I learned shallow, also very worship "" He is a person, but I still hold a very disagree with the attitude. The second opposite point of view is the father of Linux Linus. He thinks that the debugger only "fraught", will only cause people to be obsessed with the appearance rather than really understand the source code itself. In this case, the KGDB has not been built into the kernel for a long time. I think there is some truth to the idea that debugger debugging bugs introduce incorrect fixes. But instead of bringing it into the kernel as a reason, I think it makes no sense. Because Linus himself said: "I only use gdb, and I always do not use it as a debugger, but as a can be used to analyze the application of the resolver to use." "Since he can do that, why do you think that the purpose of using GDB is to debug bugs instead of using them for something else?" I say so, this is because I am also using GDB is mainly used to assist the analysis of kernel code, rather than primarily for debugging errors. This is also the subject of this article.

The world never lacks the answer to the problem, and the lack of it is the way to solve it. Now, there is no shortage of cattle books in the Linux world, will do 1000 pages of a full answer to the book of bricks, but gradually found that read the back of the reading to forget the front, back to the front has forgotten the back, even a chapter has not finished, the subsystem has been completely rewritten. Slowly, I wonder if I'm really getting old. I'm really dying. "But we never thought:" Why we are so subjection. He can figure it out, and I can't. ”。 In fact, what we need is a kind of fundamental way to forget its shape, and it needs a general solution for the soldiers to flood the block and fire. And it is by no means drowned in the conclusions of the Bulls. Otherwise, if you encounter a new problem, you can only complain that the cow's book is not thick enough to include what you need. Cattle must have a set of cattle methods, and he said in the book, I do not think he deliberately "prepared", but that it is a habit of their own negligence of things. The results of the study of cattle is not the most important, his research methods and means is the most important thing. And I also gradually found that the debugger can bring us a lot of useful hints, so that we can constantly find the inspiration and direction of thinking, but also make learning become very interesting and purposeful. I think that the use of debugger-assisted source analysis, is not what a lot of cattle are doing without saying it. No matter the answer, I still feel that the debugger is a good thing, do not easily put it aside. Although many tall people may already be deep in this way, and even do not need its hints, but it is still beneficial to me and others with shallow skills. It is certainly not a bad thing to write down this experience and skills so that those who need it are less time to grope.

It is for this reason, as the document slowly become larger, but also more feel that the title of the document is a bit inappropriate, the topic as a "core dynamic analysis Guide" more appropriate point. The gist of the document is to use the debugger to dynamically analyze the kernel, debugging errors is only a by-product of this process. However, this new name is really not enough now the name "glare", so it has not enabled it.

Said so much nonsense and out of line, nothing more than two purposes: this article slowly become so long, if there is no half sentence of "human" words, no half sentence of the real world statement. It's not like I've become a robot, and the person who reads it will become a robot. By the way, make friends with this text. Another purpose is to say that you should not be restrained in tools, tools are dead, people are alive. If certain tools can bring us some useful hints, we can try it, take advantage and discard the dross.

The original text of the quote:

Linus on how the debugger and the kernel develop: http://www.bitscn.com/linux/kernel/200604/7493.html

Where does knowledge come from?