[bootlin/training-materials updates] master: Kernel debugging lab: try to clarify the explanations (1f5955c2)

Michael Opdenacker michael.opdenacker at bootlin.com
Tue Mar 31 15:12:21 CEST 2020

Repository : https://github.com/bootlin/training-materials
On branch  : master

>---------------------------------------------------------------

commit 1f5955c2064025b7071e8093ef0bab1aee7d94cc
Author: Michael Opdenacker <michael.opdenacker at bootlin.com>
Date:   Tue Mar 31 15:11:10 2020 +0200

Kernel debugging lab: try to clarify the explanations

Signed-off-by: Michael Opdenacker <michael.opdenacker at bootlin.com>
Reported-by: Dale Stewart <dale.stewart at meresoftware.com>

>---------------------------------------------------------------

1f5955c2064025b7071e8093ef0bab1aee7d94cc
labs/kernel-debugging/kernel-debugging.tex | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/labs/kernel-debugging/kernel-debugging.tex b/labs/kernel-debugging/kernel-debugging.tex
index aa6b84a7..222a4ef8 100644
--- a/labs/kernel-debugging/kernel-debugging.tex
+++ b/labs/kernel-debugging/kernel-debugging.tex
@@ -110,15 +110,19 @@ code inside the binaries.
You could disassemble the whole \code{vmlinux} file and work with
the \code{PC} absolute address, but it is going to take a long time.

-Instead, using Elixir or \code{cscope}, find the \code{.c} source file where
-the function is implemented. In the kernel sources, you can then find
+Instead, using Elixir or \code{cscope}, you'll find that the crash
+happens in an function defined in assembly, called by a function
+implemented in C. Find the \code{.c} source file where
+the C function is implemented.
+
+In the kernel sources, you can then find
and dissassemble the corresponding \code{.o} file:

\begin{verbatim}
arm-linux-gnueabi-objdump -S file.o > file.S
\end{verbatim}

-For this need, you could also use {gdb-multiarch}\footnote{gdb-multiarch is a new package
+Another way to do this is to use {gdb-multiarch}\footnote{gdb-multiarch is a new package
supporting multiple architectures at once. If you have a cross
toolchain including gdb, you can also run arm-linux-gdb directly.}:

@@ -134,7 +138,10 @@ Then, in the disassembled code, find the start address of the
was provided in the crash output. That's how you can find the
exact assembly instruction where the crash occured, together
-with the C code it was compiled from.
+with the C code it was compiled from. Looking at the addresses
+handled by this code, you can now guess what is wrong in the
+data passed to the stack of kernel functions called by the
+broken module.

A little understanding of assembly instructions on the architecture
you are working on helps, but seeing the original C code should answer