[bootlin/training-materials updates] master: labs: debugging: replace <user> with $USER when possible (fe1873c9)
Clément Léger
clement.leger at bootlin.com
Thu Feb 2 12:17:37 CET 2023
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/fe1873c9fbf92ad51d59944a447f4007c606aa98
>---------------------------------------------------------------
commit fe1873c9fbf92ad51d59944a447f4007c606aa98
Author: Clément Léger <clement.leger at bootlin.com>
Date: Thu Feb 2 12:14:31 2023 +0100
labs: debugging: replace <user> with $USER when possible
This is way more convenient when copy/pasting commands
Signed-off-by: Clément Léger <clement.leger at bootlin.com>
>---------------------------------------------------------------
fe1873c9fbf92ad51d59944a447f4007c606aa98
.../debugging-application-crash.tex | 4 +--
.../debugging-application-profiling.tex | 12 ++++----
.../debugging-application-tracing.tex | 2 +-
.../debugging-kernel-debugging.tex | 34 +++++++++++-----------
.../debugging-memory-issues.tex | 2 +-
labs/debugging-setup/debugging-setup.tex | 9 +++---
.../debugging-system-wide-profiling.tex | 24 ++++++++++-----
7 files changed, 49 insertions(+), 38 deletions(-)
diff --git a/labs/debugging-application-crash/debugging-application-crash.tex b/labs/debugging-application-crash/debugging-application-crash.tex
index e99f27f1..87369748 100644
--- a/labs/debugging-application-crash/debugging-application-crash.tex
+++ b/labs/debugging-application-crash/debugging-application-crash.tex
@@ -25,7 +25,7 @@ fill a linked list with the names read from a file. Compile it using the
following command:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/gdb/
+$ cd /home/$USER/debugging-labs/nfsroot/root/gdb/
$ make
\end{bashinput}
@@ -99,7 +99,7 @@ Segmentation fault (core dumped)
When crashing, a \code{core} file will be generated. On your desktop computer,
fix the permissions using:
\begin{bashinput}
-$ sudo chown <user>:<user> core
+$ sudo chown $USER:$USER core
\end{bashinput}
Then, open this file using \code{gdb-multiarch}:
diff --git a/labs/debugging-application-profiling/debugging-application-profiling.tex b/labs/debugging-application-profiling/debugging-application-profiling.tex
index 2dfac75d..1874fdce 100644
--- a/labs/debugging-application-profiling/debugging-application-profiling.tex
+++ b/labs/debugging-application-profiling/debugging-application-profiling.tex
@@ -16,7 +16,7 @@ side of an application. Compile the \code{heap_profile} example that we did prov
using the following command:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/heap_profile
+$ cd /home/$USER/debugging-labs/nfsroot/root/heap_profile
$ make
\end{bashinput}
@@ -56,7 +56,7 @@ takes two parameters, an input png and an output one. We provided a
the following commands:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/app_profiling
+$ cd /home/$USER/debugging-labs/nfsroot/root/app_profiling
$ make
\end{bashinput}
@@ -71,7 +71,7 @@ generated. Once finished, on the host, fix the permissions on the
\code{callgrind.out.*} file to be able to open it with \code{Kcachegrind}:
\begin{bashinput}
-$ sudo chown <user>:<user> cachegrind.out.*
+$ sudo chown $USER:$USER cachegrind.out.*
\end{bashinput}
Analyze the results with \code{Kcachegrind} in order to understand the
@@ -88,7 +88,7 @@ $ valgrind --tool=callgrind ./png_convert tux_small.png out.png
Again, on the host platform, fix the permissions of the file using:
\begin{bashinput}
-$ sudo chown <user>:<user> callgrind.out.*
+$ sudo chown $USER:$USER callgrind.out.*
\end{bashinput}
Again, analyze the results using \code{Kcachegrind}. This time, the view is
@@ -148,7 +148,7 @@ desktop platform, display the results with \code{perf report} and compare them
with callgrind ones:
\begin{bashinput}
-$ perf report --symfs=/home/<user>/debugging-labs/buildroot/output/staging/
- -k /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+$ perf report --symfs=/home/$USER/debugging-labs/buildroot/output/staging/
+ -k /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
./png_convert tux_small.png out.png
\end{bashinput}
diff --git a/labs/debugging-application-tracing/debugging-application-tracing.tex b/labs/debugging-application-tracing/debugging-application-tracing.tex
index c5450e4a..57ba802a 100644
--- a/labs/debugging-application-tracing/debugging-application-tracing.tex
+++ b/labs/debugging-application-tracing/debugging-application-tracing.tex
@@ -13,7 +13,7 @@
On your computer, go into the \code{ltrace} lab folder:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/ltrace/
+$ cd /home/$USER/debugging-labs/nfsroot/root/ltrace/
$ make
\end{bashinput}
diff --git a/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex b/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex
index ec1d22da..cd472eef 100644
--- a/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex
+++ b/labs/debugging-kernel-debugging/debugging-kernel-debugging.tex
@@ -16,10 +16,10 @@
First, compile the module using the following command line:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/locking
-$ export CROSS_COMPILE=/home/<user>/debugging-labs/buildroot/output/host/bin/arm-linux-
+$ cd /home/$USER/debugging-labs/nfsroot/root/locking
+$ export CROSS_COMPILE=/home/$USER/debugging-labs/buildroot/output/host/bin/arm-linux-
$ export ARCH=arm
-$ export KDIR=/home/<user>/debugging-labs/buildroot/output/build/linux-5.13/
+$ export KDIR=/home/$USER/debugging-labs/buildroot/output/build/linux-5.13/
$ make
\end{bashinput}
@@ -50,7 +50,7 @@ STM32MP> boot
Then compile the kmemleak test module:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/kmemleak
+$ cd /home/$USER/debugging-labs/nfsroot/root/kmemleak
$ make
\end{bashinput}
@@ -118,7 +118,7 @@ Using \code{addr2line}, find the exact source code line were the crash happened.
For that, you can use the following command:
\begin{bashinput}
-$ addr2line -e /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+$ addr2line -e /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
-a <crash_address>
\end{bashinput}
@@ -126,7 +126,7 @@ We can even go a step further and use \code{gdb-multiarch} to open vmlinux and
locate the function and corresponding offset in assembly
\begin{bashinput}
-$ gdb-multiarch /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+$ gdb-multiarch /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
(gdb) disassemble <function>
\end{bashinput}
@@ -166,7 +166,7 @@ automatically wait for a debugger to be attached. Run \code{gdb-multiarch} and
attach a gdb process to KGDB with the following command:
\begin{bashinput}
-$ gdb-multiarch /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+$ gdb-multiarch /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
(gdb) target remote /dev/pts/8
\end{bashinput}
@@ -190,7 +190,7 @@ Then the kernel will halt during boot waiting for a GDB process to be attached.
Attached using the same command that was previously used:
\begin{bashinput}
-$ gdb-multiarch /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+$ gdb-multiarch /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
(gdb) target remote /dev/pts/8
\end{bashinput}
@@ -288,7 +288,7 @@ kexec. For that, we will use a simple buildroot image with a builtin initramfs
using the following commands:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/buildroot
+$ cd /home/$USER/debugging-labs/buildroot
$ make O=build_kexec stm32mp157a_dk1_debugging_kexec_defconfig
$ cd build_kexec
$ make -j<x>
@@ -298,9 +298,9 @@ Then, we'll copy the zImage and the device-tree to the nfs /root/kexec
directory:
\begin{bashinput}
-$ mkdir /home/<user>/debugging-labs/nfsroot/root/kexec
-$ cp build_kexec/images/zImage /home/<user>/debugging-labs/nfsroot/root/kexec
-$ cp build_kexec/images/stm32mp157a-dk1.dtb /home/<user>/debugging-labs/nfsroot/root/kexec
+$ mkdir /home/$USER/debugging-labs/nfsroot/root/kexec
+$ cp images/zImage /home/$USER/debugging-labs/nfsroot/root/kexec
+$ cp images/stm32mp157a-dk1.dtb /home/$USER/debugging-labs/nfsroot/root/kexec
\end{bashinput}
These files are now ready to be used from the target using kexec.
@@ -354,8 +354,8 @@ $ ifconfig eth0 192.168.0.101
boot so this commands needs to be run another time.}
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/
-$ scp root at 192.168.0.101:/proc/vmcore ./vmcore
+$ cd /home/$USER/debugging-labs/
+$ scp root at 192.168.0.100:/proc/vmcore ./vmcore
\end{bashinput}
Finally, we will be able to debug that kernel coredump using crash.
@@ -368,7 +368,7 @@ following commands:
\begin{bashinput}
$ sudo apt install gcc-multilib g++-multilib lib32z1-dev lib32ncurses5-dev texinfo bison
-$ cd /home/<user>/debugging-labs/
+$ cd /home/$USER/debugging-labs/
$ git clone https://github.com/crash-utility/crash.git
$ cd crash
$ make target=ARM
@@ -376,8 +376,8 @@ $ make target=ARM
Once done, you can open the vmcore file with crash using
\begin{bashinput}
-$ ./crash /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
- /home/<user>/debugging-labs/vmcore
+$ ./crash /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+ /home/$USER/debugging-labs/vmcore
\end{bashinput}
Take some times to analyze the content of the dump using the commands that are
diff --git a/labs/debugging-memory-issues/debugging-memory-issues.tex b/labs/debugging-memory-issues/debugging-memory-issues.tex
index 9344cb8a..2f5f7047 100644
--- a/labs/debugging-memory-issues/debugging-memory-issues.tex
+++ b/labs/debugging-memory-issues/debugging-memory-issues.tex
@@ -13,7 +13,7 @@ Go into the \code{valgrind folder} and compile \code{valgrind.c} with debugging
information using:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/valgrind
+$ cd /home/$USER/debugging-labs/nfsroot/root/valgrind
$ make
\end{bashinput}
diff --git a/labs/debugging-setup/debugging-setup.tex b/labs/debugging-setup/debugging-setup.tex
index 37f3d595..2a62d5d1 100644
--- a/labs/debugging-setup/debugging-setup.tex
+++ b/labs/debugging-setup/debugging-setup.tex
@@ -13,7 +13,7 @@ we need (tools, configured kernel, etc). This image will be built with buildroot
which allows to build a complete image for embedded systems.
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/
+$ cd /home/$USER/debugging-labs/
$ git clone https://github.com/bootlin/buildroot
$ cd buildroot
$ git checkout debugging-training/2022.08
@@ -26,18 +26,18 @@ contain the images that can be used on the board. During this course, we will
use a kernel located on a sdcard and a rootfs via NFS. This will let us transfer
data freely from and to the target board.
-The rootfs should be extracted at \code{/home/<user>/debugging-labs/nfsroot}
+The rootfs should be extracted at \code{/home/$USER/debugging-labs/nfsroot}
using this command:
\begin{bashinput}
-$ tar xvf output/images/rootfs.tar -C /home/<user>/debugging-labs/nfsroot
+$ tar xvf output/images/rootfs.tar -C /home/$USER/debugging-labs/nfsroot
\end{bashinput}
We will also export the \code{CROSS_COMPILE} variable to set the toolchain as our
cross compiling toolchain:
\begin{bashinput}
-$ export CROSS_COMPILE=/home/<user>/debugging-labs/buildroot/output/host/bin/arm-linux-
+$ export CROSS_COMPILE=/home/$USER/debugging-labs/buildroot/output/host/bin/arm-linux-
\end{bashinput}
This export needs to be either done in each shell in which \code{CROSS_COMPILE} is
@@ -129,3 +129,4 @@ STM32MP1> env set bootargs root=/dev/nfs ip=192.168.0.100:::::eth0
STM32MP1> saveenv
\end{bashinput}
+NOTE: Be sure to replace the \code{<user>} string with the correct user.
diff --git a/labs/debugging-system-wide-profiling/debugging-system-wide-profiling.tex b/labs/debugging-system-wide-profiling/debugging-system-wide-profiling.tex
index 9e848c3e..9e4db069 100644
--- a/labs/debugging-system-wide-profiling/debugging-system-wide-profiling.tex
+++ b/labs/debugging-system-wide-profiling/debugging-system-wide-profiling.tex
@@ -46,7 +46,7 @@ manually with the uprobe sysfs interface or using \code{perf probe}.
Before starting to profile, we will compile our program to be instrumented:
\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/system_profiling
+$ cd /home/$USER/debugging-labs/nfsroot/root/system_profiling
$ make
\end{bashinput}
@@ -67,10 +67,20 @@ Then, we can create a uprobe and capture the crc value using:
$ perf probe --source=./ -x ./crc_random main:35 crc
\end{bashinput}
-We can finally trace the application using trace-cmd with this event
+We can finally trace the application using \code{trace-cmd} with this event. We will
+use the remote tracing capabilities of \code{trace-cmd} top do that. First, we will
+start the \code{trace-cmd} server on the desktop platform:
\begin{bashinput}
-$ trace-cmd record -e probe_crc_random:main_L35 ./crc_random
+trace-cmd listen -p 4567
+\end{bashinput}
+
+Then, on the target, run \code{trace-cmd} with the \code{-N} parameter to
+specify the remote trace-cmd server. Interrupt it after a few (~50) crc
+computations in order to have a meaningful trace.
+
+\begin{bashinput}
+$ trace-cmd record -N 192.168.0.1:4567 -e probe_crc_random:main_L35 ./crc_random
^C
\end{bashinput}
@@ -204,15 +214,15 @@ computer for further analysis. Copy that file and fix the permissions using
\code{chown}:
\begin{bashinput}
-$ sudo cp /home/<user>/debugging-labs/nfsroot/root/system_profiling/perf.data .
-$ sudo chown <user>:<user> perf.data
+$ sudo cp /home/$USER/debugging-labs/nfsroot/root/system_profiling/perf.data .
+$ sudo chown $USER:$USER perf.data
\end{bashinput}
We will then use perf report to visualize the aquired data:
\begin{bashinput}
-$ perf report --symfs=/home/<user>/debugging-labs/buildroot/output/staging/
- -k /home/<user>/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
+$ perf report --symfs=/home/$USER/debugging-labs/buildroot/output/staging/
+ -k /home/$USER/debugging-labs/buildroot/output/build/linux-5.13/vmlinux
\end{bashinput}
Another useful tool for performance analysis is flamegraphs. Latest perf
More information about the training-materials-updates
mailing list