[bootlin/training-materials updates] master: debugging: Various minor fixes/typos/spelling mistakes/display artefacts (fea36ea3)
Miquel Raynal
miquel.raynal at bootlin.com
Fri Nov 18 12:52:29 CET 2022
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/fea36ea361c60f5f095882ae7a09f7a05ca5ef04
>---------------------------------------------------------------
commit fea36ea361c60f5f095882ae7a09f7a05ca5ef04
Author: Miquel Raynal <miquel.raynal at bootlin.com>
Date: Fri Nov 18 12:52:14 2022 +0100
debugging: Various minor fixes/typos/spelling mistakes/display artefacts
Signed-off-by: Miquel Raynal <miquel.raynal at bootlin.com>
>---------------------------------------------------------------
fea36ea361c60f5f095882ae7a09f7a05ca5ef04
common/scheduling-classes.tex | 2 +-
.../debugging-application-debugging.tex | 18 ++--
.../debugging-application-profiling.tex | 25 +++--
.../debugging-application-tracing.tex | 20 ++--
.../debugging-common-tools.tex | 32 +++----
.../debugging-kernel-debugging.tex | 40 ++++----
.../debugging-linux-application-stack.tex | 32 +++----
.../debugging-memory-issues.tex | 16 ++--
.../debugging-system-wide-profiling.tex | 106 ++++++++++-----------
9 files changed, 145 insertions(+), 146 deletions(-)
diff --git a/common/scheduling-classes.tex b/common/scheduling-classes.tex
index 880865fb..597ec1ac 100644
--- a/common/scheduling-classes.tex
+++ b/common/scheduling-classes.tex
@@ -3,7 +3,7 @@
\begin{itemize}
\item The Linux Kernel Scheduler is a key piece in having a real-time behaviour
\item It is in charge of deciding which \textbf{runnable} task gets executed
- \item It also elects on which CPU the task runs, and it tightly coupled to CPUidle and CPUFreq
+ \item It also elects on which CPU the task runs, and is tightly coupled to CPUidle and CPUFreq
\item It schedules both \textbf{userspace} tasks, but also \textbf{kernel} tasks
\item Each task is assigned one \textbf{scheduling class} or \textbf{policy}
\item The class determines the algorithm used to elect each task
diff --git a/slides/debugging-application-debugging/debugging-application-debugging.tex b/slides/debugging-application-debugging/debugging-application-debugging.tex
index 78a6e105..4f70295c 100644
--- a/slides/debugging-application-debugging/debugging-application-debugging.tex
+++ b/slides/debugging-application-debugging/debugging-application-debugging.tex
@@ -8,7 +8,7 @@
\item Some values might be optimized out and thus not accessible when
debugging.
\item Same goes for static functions, they are often folded into the caller
- and thus won't be displayed in backtraces
+ and thus won't be displayed in backtraces.
\end{itemize}
\end{frame}
@@ -17,7 +17,7 @@
\begin{itemize}
\item Displaying a backtrace from your application were the crash happened
is useful to debug and can be done using \code{backtrace()}
- (\manpage{backtrace}{3}GNU extension function:
+ (\manpage{backtrace}{3}) GNU extension function:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{c}
@@ -26,12 +26,11 @@ char **backtrace_symbols(void *const *buffer, int size);
\end{block}
\begin{itemize}
- \item LibSegFault is a library that will allow to automatically display a
+ \item \code{libSegFault.so} is a library that will allow to automatically display a
backtrace and more information when your program does generate a
segfault.
- \item {\em LibSegFault.so} is provided by the glibc and is available for
- many architectures
- \item Can be used without recompilation by preloading it with \code{LD_PRELOAD}
+ \item It is provided by the glibc and is available for many architectures.
+ \item Can be used without recompilation by preloading it with \code{LD_PRELOAD}.
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{console}
@@ -88,7 +87,6 @@ Memory map:
\end{center}
\end{frame}
-
\begin{frame}
\frametitle{GDB Python Extension}
\begin{itemize}
@@ -96,11 +94,11 @@ Memory map:
allowing to script some debugging operations
\item When executing python under GDB, a module named {\em gdb} is available
and all the GDB specific classes are accessible under this module
- \item Allow to add new types of commands, breakpoint, printers
+ \item Allows to add new types of commands, breakpoint, printers
\begin{itemize}
\item Used by the kernel to create new commands with the python GDB scripts
\end{itemize}
- \item Allow full control and observability over the debugged program using
+ \item Allows full control and observability over the debugged program using
GDB capabilities from Python scripts
\begin{itemize}
\item Controlling execution, adding breakpoints, watchpoints, etc
@@ -146,7 +144,7 @@ TraceFDs()
\begin{frame}[fragile]
\frametitle{GDB Python Extension (2/2)}
\begin{itemize}
- \item Python script can be loaded using gdb \code{source} command
+ \item Python scripts can be loaded using gdb \code{source} command
\begin{itemize}
\item Or the script can be named <program>-gdb.py and will be loaded automatically by GDB
\end{itemize}
diff --git a/slides/debugging-application-profiling/debugging-application-profiling.tex b/slides/debugging-application-profiling/debugging-application-profiling.tex
index f2b66eba..1a22f92c 100644
--- a/slides/debugging-application-profiling/debugging-application-profiling.tex
+++ b/slides/debugging-application-profiling/debugging-application-profiling.tex
@@ -54,7 +54,7 @@
\frametitle{Visualizing data with flamegraphs}
\begin{itemize}
\item Visualization based on hierarchical stacks
- \item Allow to quickly find bottlenecks and explore the call stack
+ \item Allows to quickly find bottlenecks and explore the call stack
\item Popularized by Brendan Gregg tools which allows to generate
flamegraphs from \code{perf} results.
\begin{itemize}
@@ -177,11 +177,11 @@ Number of snapshots: 52
\end{itemize}
\item Finer tracking than with Massif and visualizing tool is more advanced.
\begin{itemize}
- \item Each allocation is associated to a stacktrace
+ \item Each allocation is associated to a stacktrace.
\item Allows finding memory leaks, allocation hotspots and
temporary allocations.
\end{itemize}
- \item Results can be seen using GUI (\code{heaptrack_gui} or CLI tool
+ \item Results can be seen using GUI (\code{heaptrack_gui}) or CLI tool
(\code{heaptrack_print}).
\item \url{https://github.com/KDE/heaptrack}
\end{itemize}
@@ -212,11 +212,10 @@ $ heaptrack program
\item memusage is a program that leverages \code{libmemusage.so} to profile
memory usage (\manpage{memusage}{1}) (user-space only).
\item Can profile heap, stack and also mmap memory usage.
- \item Profiling is output on the console or a PNG file can be generated
- but can also output data to a a binary file for post-treatment by
- other tools.
+ \item Profiling information can be shown on the console, logged to
+ a file for post-treatment or catch on a PNG file.
\item Lightweight solution compared to valgrind {\em Massif} tool since it
- uses \code{LD_PRELOAD} mechanism.
+ uses the \code{LD_PRELOAD} mechanism.
\end{itemize}
\column{0.3\textwidth}
\includegraphics[width=\textwidth]{../slides/debugging-application-profiling/memusage.png}
@@ -278,7 +277,7 @@ Histogram for block sizes:
limited.
\item Requesting more events than possible will result in multiplexing and
perf will scale the results.
- \item Collected performance counters result are then approximate.
+ \item Collected performance counters are then approximate.
\begin{itemize}
\item To acquire more precise numbers, reduce the number of events
observed and run \code{perf} multiple times changing the events set
@@ -358,14 +357,14 @@ Performance counter stats for 'cat /etc/fstab':
\begin{frame}[fragile]
\frametitle{{\em Cachegrind}}
\begin{itemize}
- \item This tools provided by valgrind allows to profile program interactions
- with the instruction and data cache hierarchy.
+ \item {\em Cachegrind} is a tool provided by {\em valgrind} for
+ profiling program interactions with the instruction and data cache hierarchy.
\begin{itemize}
\item {\em Cachegrind} also profiles branch prediction success.
\end{itemize}
\item Simulate a machine with independent \code{I$} and \code{D$} backed
with a unified L2 cache.
- \item Really helpful to detect cache usage problems (Too many misses, etc).
+ \item Really helpful to detect cache usage problems (too many misses, etc).
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{console}
@@ -388,11 +387,11 @@ $ valgrind --tool=cachegrind ./my_program
\begin{frame}[fragile]
\frametitle{{\em Callgrind}}
\begin{itemize}
- \item Provided by valgrind and allows to profile an application call graph
+ \item Provided by {\em valgrind} and allowing to profile an application call graph
(user-space only).
\item Collects the number of instructions executed during your program
execution and associate these data with the source lines
- \item Record the call relationship between functions and their call
+ \item Records the call relationship between functions and their call
count.
\begin{block}{}
\begin{minted}[fontsize=\small]{console}
diff --git a/slides/debugging-application-tracing/debugging-application-tracing.tex b/slides/debugging-application-tracing/debugging-application-tracing.tex
index 3cfa09be..85f2be00 100644
--- a/slides/debugging-application-tracing/debugging-application-tracing.tex
+++ b/slides/debugging-application-tracing/debugging-application-tracing.tex
@@ -12,8 +12,8 @@
loaded before any other library by the dynamic loader.
\item Allows to intercept all library calls by preloading another library.
\begin{itemize}
- \item Override libraries symbols that have the same name.
- \item Allow to redefine only a few specific symbols.
+ \item Overrides libraries symbols that have the same name.
+ \item Allows to redefine only a few specific symbols.
\end{itemize}
\item Used by some debugging/tracing libraries ({\em libsegfault},
{\em libefence})
@@ -24,7 +24,7 @@
\begin{frame}[fragile]
\frametitle{{\em LD\_PRELOAD} example}
\begin{itemize}
- \item Code for library that will be preloaded using {\em LD\_PRELOAD}:
+ \item Library snippet that we want to preload using {\em LD\_PRELOAD}:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{c}
@@ -62,8 +62,8 @@ $ LD_PRELOAD=my_lib.so ./exe
userspace code.
\item Tracepoints can be added dynamically on any userspace symbol
\begin{itemize}
- \item Internally patches the text section with breakpoint that is handled
- by the kernel trace system
+ \item Internally patches the \code{.text} section with breakpoints
+ that are handled by the kernel trace system
\end{itemize}
\item Exposed by file \code{/sys/kernel/debug/tracing/uprobe_events}
\item Often wrapped up by other tools (\code{perf}, \code{bcc} for
@@ -76,14 +76,14 @@ $ LD_PRELOAD=my_lib.so ./exe
\frametitle{The {\em perf} tool}
\begin{itemize}
\item {\em perf} tool was started as a tool to profile application under
- Linux using performance counter (\manpage{perf}{1}).
+ Linux using performance counters (\manpage{perf}{1}).
\item It became much more than that and now allows to insert tracepoints,
kprobes and uprobes.
\item {\em perf} can profile both user-space and kernel-space execution.
\item {\em perf} is based on the \code{perf_event} interface that is
exposed by the kernel.
\item {\em perf} provides a set of operations that each have specific
- arguments (see \code{perf help}).
+ arguments (see {\em perf} help).
\begin{itemize}
\item \code{stat}, \code{record}, \code{report}, \code{top}, \code{annotate}, \code{ftrace}, \code{list}, \code{probe}, etc
\end{itemize}
@@ -101,7 +101,7 @@ $ LD_PRELOAD=my_lib.so ./exe
\item \code{perf.data} file can then be analyzed using \code{perf annotate}
and \code{perf report}.
\begin{itemize}
- \item Often useful on embedded systems to analyze data on another computer.
+ \item Useful on embedded systems to analyze data on another computer.
\end{itemize}
\end{itemize}
\end{frame}
@@ -109,7 +109,7 @@ $ LD_PRELOAD=my_lib.so ./exe
\begin{frame}[fragile]
\frametitle{Probing userspace functions}
\begin{itemize}
- \item Create tracepoints on function in a user-space library/executable:
+ \item Create tracepoints on user-space library/executable functions:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\scriptsize]{C}
@@ -118,7 +118,7 @@ $ perf probe -x app my_func
\end{minted}
\end{block}
\begin{itemize}
- \item Recording execution of these tracpoints:
+ \item Record the execution of these tracepoints:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\scriptsize]{C}
diff --git a/slides/debugging-common-tools/debugging-common-tools.tex b/slides/debugging-common-tools/debugging-common-tools.tex
index c6b72aee..557e3432 100644
--- a/slides/debugging-common-tools/debugging-common-tools.tex
+++ b/slides/debugging-common-tools/debugging-common-tools.tex
@@ -38,7 +38,8 @@
\item\code{/proc/<pid>/status} process basic information
\item \code{/proc/<pid>/maps} process memory mappings
\item \code{/proc/<pid>/fd} file descriptors of the process
- \item \code{/proc/<pid>/task} file descriptors of the process
+ \item \code{/proc/<pid>/task} descriptors of threads belonging
+ to the process
\end{itemize}
\item \code{/proc/self/} will refer to the process used to access the file
\item \code{/proc/sys/} contains system parameters that can be tuned. The
@@ -47,7 +48,7 @@
\item \code{/proc/irq/<irq>} interrupt information.
\end{itemize}
\item A list of all available {\em procfs} file and their content is
- described at \kdochtml{filesystems/proc}
+ described at \kdochtml{filesystems/proc} and \manpage{proc}{5}
\end{itemize}
\end{frame}
@@ -61,7 +62,7 @@
file hierarchy representing the kernel internal tree of devices.
\item \code{/sys/kernel} contains interesting files for kernel debugging:
\begin{itemize}
- \item \code{irq} with information about irq (mapping, count, etc).
+ \item \code{irq} with information about interrupts (mapping, count, etc).
\item \code{tracing} for tracing control.
\end{itemize}
\item \kdochtml{admin-guide/abi-stable}
@@ -78,7 +79,7 @@
display debugging information related to the internals.
\item Usually mounted on \code{/sys/kernel/debug}
\begin{itemize}
- \item Dynamic debug features exposes through \code{/sys/kernel/debug/dynamic_debug}.
+ \item Dynamic debug features exposed through \code{/sys/kernel/debug/dynamic_debug}.
\item Clock tree exposed through \code{/sys/kernel/debug/clk/clk_summary}.
\end{itemize}
\end{itemize}
@@ -90,18 +91,17 @@
\item The binutils are used to deal with binary files, either object files
or executables.
\begin{itemize}
- \item Includes \code{ld}, \code{as}, and other useful tools.
+ \item Includes \code{ld}, \code{as} and other useful tools.
\end{itemize}
\item {\em readelf} displays information about ELF files (header, section,
segments, etc).
\item {\em objdump} allows to display information and disassemble ELF
files.
- \item {\em objcopy} can convert the ELF files or extract, translate some
+ \item {\em objcopy} can convert ELF files or extract/translate some
parts of it.
- \item {\em nm} displays the list of symbols that are embedded in the ELF
- file.
- \item {\em addr2line} find a source code line/file pair from address using
- an elf file with debug info
+ \item {\em nm} displays the list of symbols embedded in ELF files.
+ \item {\em addr2line} finds the source code line/file pair from an address using
+ an ELF file with debug information
\end{itemize}
\end{frame}
@@ -210,15 +210,15 @@ liblqr-1.so.0 => /lib/x86_64-linux-gnu/liblqr-1.so.0 (0x00007fb4b6e00000)
their associated information (\manpage{ps}{1})
\begin{itemize}
\item Lists both user processes and kernel threads.
- \item Display PID, CPU usage, memory usage, uptime, etc.
+ \item Displays PID, CPU usage, memory usage, uptime, etc.
\end{itemize}
\begin{itemize}
\item Uses {\em /proc/<pid>/} directory to obtain process information.
\item Always present on almost all embedded platforms (provided by
- {\em busybox}).
+ {\em Busybox}).
\end{itemize}
\item By default, displays only the current user/current tty processes.
- \item Useful for scripting and parsing since output is static.
+ \item Useful for scripting and parsing since its output is static.
\end{itemize}
\end{frame}
@@ -255,7 +255,7 @@ vnstat 987 0.0 0.0 5516 3696 ? Ss 09:08 0:00 /usr/sbin/vns
and interactive (\manpage {top}{1}).
\begin{itemize}
\item Also almost always present on embedded platforms (provided by
- {\em busybox})
+ {\em Busybox})
\end{itemize}
\end{itemize}
\begin{block}{}
@@ -303,7 +303,7 @@ Swap: 14Gi 20Mi 14Gi
\item {\em vmstat} displays information about system virtual memory usage
\item Can also display stats from processes, memory, paging, block IO,
traps, disks and cpu activity (\manpage{vmstat}{8}).
- \item Can be used to gather data at periodic interval using {\em vmstat <interval> <number>}
+ \item Can be used to gather data at periodic interval using \code{vmstat <interval> <number>}
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\footnotesize]{console}
@@ -399,7 +399,7 @@ Current DISK READ: 20.61 K/s | Current DISK WRITE: 24.04 K/s
\begin{frame}[fragile]
\frametitle{pmap}
\begin{itemize}
- \item \code{pmap} tool allows to display process mappings more easily than
+ \item \code{pmap} displays process mappings more easily than
accessing \code{/proc/<pid>/maps} (\manpage{pmap}{1}).
\end{itemize}
\begin{block}{}
diff --git a/slides/debugging-kernel-debugging/debugging-kernel-debugging.tex b/slides/debugging-kernel-debugging/debugging-kernel-debugging.tex
index 793b01a7..c8fd9512 100644
--- a/slides/debugging-kernel-debugging/debugging-kernel-debugging.tex
+++ b/slides/debugging-kernel-debugging/debugging-kernel-debugging.tex
@@ -26,9 +26,9 @@
\begin{itemize}
\item Compiling the kernel yields a number of files
\item Amongst the various images and files that are generated, some of them
- are interesting for the debug
+ are interesting for debugging purposes:
\begin{itemize}
- \item \code{vmlinux}: Kernel elf file used for debug and to derivate other
+ \item \code{vmlinux}: Kernel ELF file used for debug and to derivate other
images
\item \code{System.map}: Contain a list of addresses/symbols that are
embedded in the kernel
@@ -44,7 +44,7 @@
crashes
\begin{itemize}
\item Memory access error (NULL pointer, out of bounds access, etc)
- \item Voluntarily panicking on error detection (Using {\em PANIC()})
+ \item Voluntarily panicking on error detection (using \kfunc{panic})
\item Kernel incorrect execution mode (sleeping in atomic context)
\item Deadlocks detected by the kernel (Soft lockup/locking problem)
\end{itemize}
@@ -103,8 +103,8 @@
\item \kconfig{CONFIG_PANIC_TIMEOUT}: Number of second after which the
kernel will reboot
\begin{itemize}
- \item 0: Never reboot
- \item Negative value: Reboot immediately
+ \item 0: never reboots
+ \item Negative value: reboot immediately
\item Positive value: seconds to wait before rebooting
\end{itemize}
\item Tasks that are taking too much time to execute and that are hung can
@@ -118,15 +118,15 @@
\frametitle{Kernel crash post-mortem analysis}
\begin{itemize}
\item Sometimes, accessing the crashed system is not possible or the system
- can't stay offline while waiting to be debugued
+ can't stay offline while waiting to be debugged
\item Kernel can generate crash dumps (a {\em vmcore} file) to a remote
- location allowing to restart system quickly and do a post mortem
- analysis of crash using GDB.
- \item This feature relies on {\em kexec} and {\em kdump} which allows
- booting another kernel as soon as the crash occurs and dumping the
- vmcore
+ location, allowing to quickly restart the system while still
+ be able to perform post-mortem analysis with GDB.
+ \item This feature relies on {\em kexec} and {\em kdump} which will
+ boot another kernel as soon as the crash occurs right after dumping the
+ {\em vmcore} file.
\begin{itemize}
- \item {\em vmcore} file can be saved on local storage, via SSH, FTP etc.
+ \item The {\em vmcore} file can be saved on local storage, via SSH, FTP etc.
\end{itemize}
\end{itemize}
\end{frame}
@@ -467,10 +467,10 @@ $ target remote localhost:5551
\item Locking issues (unbalanced locking)
\item Address space issues, such as accessing user space pointer directly
\end{itemize}
- \item Analysis can be run using \code{make C=2} to run only on file that are
+ \item Analysis can be run using \code{make C=2} to run only on files that are
recompiled
\item Or with \code{make C=1} to run on all files
- \item Example of a unbalanced locking scheme:
+ \item Example of an unbalanced locking scheme:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{console}
@@ -544,7 +544,11 @@ R13: 0000000000005490 R14: 00000000006ed530 R15: 00007fb5ef0e3700
\item When writing driver code, never expect the user to provide correct
values. Always check these values.
\item Use the \kfunc{WARN_ON} macro if you want to display a stacktrace when
- a specific condition did happen
+ a specific condition did happen.
+ \begin{itemize}
+ \item \kfunc{dump_stack} can also be used during debugging to
+ show the current call stack.
+ \end{itemize}
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{C}
@@ -561,8 +565,8 @@ static bool check_flags(u32 flags)
\begin{frame}[fragile]
\frametitle{Good practices in kernel development (2/2)}
\begin{itemize}
- \item If the value can be checked at compile time (configuration input,
- sizeof struct fields), use the \kfunc{BUILD_BUG_ON} macro to
+ \item If the values can be checked at compile time (configuration input,
+ \kfunc{sizeof} structure fields), use the \kfunc{BUILD_BUG_ON} macro to
ensure the condition is true.
\end{itemize}
\begin{block}{}
@@ -573,7 +577,7 @@ BUILD_BUG_ON(sizeof(ctx->__reserved) != sizeof(reserved));
\begin{itemize}
\item If during compilation you have some warnings about unused
variables/parameters, they must be fixed.
- \item Apply \code{checkpatch.pl} when possible which might find some
+ \item Apply \code{checkpatch.pl --strict} when possible which might find some
potential problems in your code.
\end{itemize}
\end{frame}
diff --git a/slides/debugging-linux-application-stack/debugging-linux-application-stack.tex b/slides/debugging-linux-application-stack/debugging-linux-application-stack.tex
index f9b22548..bff0f389 100644
--- a/slides/debugging-linux-application-stack/debugging-linux-application-stack.tex
+++ b/slides/debugging-linux-application-stack/debugging-linux-application-stack.tex
@@ -12,7 +12,7 @@
the same
\end{itemize}
\item Allow the kernel to control the full processor state (handle
- exceptions, MMU etc) whereas the userspace can only do basic control
+ exceptions, MMU, etc) whereas the userspace can only do basic control
and execute under the kernel supervision.
\end{itemize}
\end{frame}
@@ -55,11 +55,11 @@
\begin{itemize}
\item Internally, both will call \code{clone()} with different flags
\end{itemize}
- \item At one moment, only one task is executing on a CPU core and is
+ \item At any moment, only one task is executing on a CPU core and is
accessible using \kfunc{get_current} function (defined by
architecture and often stored in a register).
- \item Each CPU core will execute a different task and a task can only be
- executing on one core at a time.
+ \item Each CPU core will execute a different task.
+ \item A task can only be executing on one core at a time.
\end{itemize}
\end{frame}
@@ -94,7 +94,7 @@
\begin{itemize}
\item But share the same kernel mappings
\end{itemize}
- \item By default, all user mapping addresses are randomize to
+ \item By default, all user mapping addresses are randomized to
minimize attack surface (base of heap, stack, text, data, etc).
\begin{itemize}
\item {\bf A}ddress {\bf S}pace {\bf L}ayout {\bf R}andomization
@@ -133,16 +133,16 @@
\begin{frame}[fragile]
\frametitle{Userspace memory segments}
\begin{itemize}
- \item When starting a process, the kernel setup a number of various memory
- segments (name VMAs and backed by \kstruct{vma}) that have
- different execution attribute.
+ \item When starting a process, the kernel setups a number of various memory
+ segments (named VMAs and backed by \kstruct{vma}) that have
+ different execution attributes.
\item VMA are actually memory zones that are mapped with specific
attributes (R/W/X).
\item Segmentation fault happens when a program tries to access a non
existent VMA or a correct one but in a way that is not allowed.
\begin{itemize}
\item Writing data in a read-only segment
- \item Execute data from a non-executable segment
+ \item Executing data from a non-executable segment
\end{itemize}
\item New memory zones can be created using \code{mmap()}
(\manpage{mmap}{2})
@@ -183,7 +183,7 @@
\frametitle{Process context}
\begin{itemize}
\item The \emph{process context} can be seen as the content of
- the registers associated to a process: execution register, stack register...
+ the CPU registers associated to a process: execution register, stack register...
\item This context also designate an execution state and allows to sleep
inside kernel mode.
\item A process that is executing in process context can be preempted.
@@ -200,7 +200,7 @@
\item The scheduler can be invoked for various reasons
\begin{itemize}
\item On a periodic tick caused by interrupt (\kconfig{HZ})
- \item On a programmed interrupt on tickless system (\kconfigval{CONFIG_NO_HZ}{y})
+ \item On a programmed interrupt on tickless systems (\kconfigval{CONFIG_NO_HZ}{y})
\item Voluntarily by calling \kfunc{schedule} in code
\item Implicitly by calling functions that can sleep (blocking
operations such as \kfunc{kmalloc}, \kfunc{wait_event}).
@@ -459,7 +459,7 @@ root 11 2 [rcu_tasks_kthread] TS
\begin{itemize}
\item File starting with a header which holds binary structures
defining the file
- \item Collection of segments and sections that contains data
+ \item Collection of segments and sections that contain data
\begin{itemize}
\item \code{.text} section: Code
\item \code{.data} section: Data
@@ -488,7 +488,7 @@ root 11 2 [rcu_tasks_kthread] TS
\begin{itemize}
\item GDB uses ELF files since they are containing the debug information
\item Debug information uses the DWARF format
- \item Allows the debugger to match addresses and symbols names, call
+ \item Allows the debugger to match addresses and symbol names, call
sites, etc
\item Debugging information are generated by GDB and are included in the
ELF file if compiled with \code{-g}
@@ -519,7 +519,7 @@ $ gcc -g file.c -o program
\item If one wants to inspect variables and functions, it is possible to
compile the code using -O0 (no optimization).
\begin{itemize}
- \item {\em Note: The kernel can not be compiled with option below -O2}
+ \item {\em Note: The kernel can only be compiled with -O2 or -Os}
\end{itemize}
\item It is also possible to annotate function with compiler attributes:
\begin{itemize}
@@ -568,10 +568,10 @@ $ gcc -g file.c -o program
\item kprobes can hook handlers on almost any code site
\item ftrace allows tracing functions using different tracers
\item eBPF is a powerful framework in the kernel allowing to use BPF
- language in sandboxed environment and execute complex actions and
+ language in sandboxed environments and execute complex actions and
data gathering
\end{itemize}
- \item Some debug features uses the {\em debugfs} filesystem to expose their
+ \item Some debug features use the {\em debugfs} filesystem to expose their
functionalities.
\begin{itemize}
\item \codewithhash{\# mount -t debugfs none /sys/kernel/debug/}
diff --git a/slides/debugging-memory-issues/debugging-memory-issues.tex b/slides/debugging-memory-issues/debugging-memory-issues.tex
index 1c0d5fbe..f1213203 100644
--- a/slides/debugging-memory-issues/debugging-memory-issues.tex
+++ b/slides/debugging-memory-issues/debugging-memory-issues.tex
@@ -6,9 +6,9 @@
\item Programming (almost) always involves accessing memory
\item If done incorrectly, a large variety of errors can be triggered
\begin{itemize}
- \item Segmentation Fault can happen when accessing invalid memory
+ \item Segmentation Faults can happen when accessing invalid memory
addresses (NULL pointers or use-after-free for instance)
- \item Buffer Overflow can happen if accessing a buffer outside its
+ \item Buffer Overflows can happen if accessing a buffer outside its
boundaries
\item Memory Leaks when allocating memory and forgetting to free it after
usage
@@ -18,9 +18,9 @@
\end{frame}
\begin{frame}[fragile]
- \frametitle{Segmentation Fault}
+ \frametitle{Segmentation Faults}
\begin{itemize}
- \item Segmentation Fault are generated by the kernel when a program tries to
+ \item Segmentation Faults are generated by the kernel when a program tries to
access a memory area that it is not allowed to or to access it in an
incorrect way
\begin{itemize}
@@ -52,13 +52,13 @@ Segmentation fault
\end{frame}
\begin{frame}[fragile]
- \frametitle{Buffer Overflow}
+ \frametitle{Buffer Overflows}
\begin{itemize}
- \item Buffer Overflow are easily triggered when accessing an array outside
+ \item Buffer Overflows are easily triggered when accessing an array outside
of its boundaries (most often past the end)
\item Such access might generate a crash or not depending on the access
\begin{itemize}
- \item Writing past the end of an \code{malloced()} array will most often
+ \item Writing past the end of a \code{malloc()}'ed array will most often
overwrite the malloc data structure leading to corruption
\item Writing past the end of an array allocated on the stack can corrupt
data on the stack
@@ -135,7 +135,7 @@ void func1(void) {
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\small]{console}
- $ valgrind --leak-check=full <program>
+ $ valgrind --tool=memcheck --leak-check=full <program>
\end{minted}
\end{block}
\column{0.2\textwidth}
diff --git a/slides/debugging-system-wide-profiling/debugging-system-wide-profiling.tex b/slides/debugging-system-wide-profiling/debugging-system-wide-profiling.tex
index dc3ccd1d..c69d4ea9 100644
--- a/slides/debugging-system-wide-profiling/debugging-system-wide-profiling.tex
+++ b/slides/debugging-system-wide-profiling/debugging-system-wide-profiling.tex
@@ -5,7 +5,7 @@
\begin{itemize}
\item Sometimes, the problems are not tied to an application but rather
due to the usage of multiple layers (drivers, application, kernel).
- \item In that case, it might be useful to analyze the whole stack
+ \item In that case, it might be useful to analyze the whole stack.
\item The kernel already includes a large number of tracepoints that can be
recorded using specific tools.
\item New tracepoints can also be created statically or dynamically using
@@ -22,9 +22,9 @@
\item Uses code patching to modify text code to insert calls to specific
handlers
\begin{itemize}
- \item Kprobes allows to execute specific handlers when the hooked
+ \item \code{kprobes} allows to execute specific handlers when the hooked
instruction is executed
- \item kretprobes will trigger when returning from a function allowing to
+ \item \code{kretprobes} will trigger when returning from a function allowing to
extract the return value of functions but also display the
parameters that were used for the function call
\end{itemize}
@@ -41,9 +41,9 @@
\begin{frame}[fragile]
\frametitle{Registering a Kprobe}
\begin{itemize}
- \item Kprobes can be registered dynamically by loading a module that
+ \item \code{kprobes} can be registered dynamically by loading a module that
registers a \kstruct{kprobe} with \kfunc{register_kprobe}
- \item Probe should be unregistered at module exit using
+ \item Probes should be unregistered at module exit using
\kfunc{unregister_kprobe}
\end{itemize}
@@ -63,7 +63,7 @@ register_kprobe(&probe);
\begin{frame}[fragile]
\frametitle{Registering a kretprobe}
\begin{itemize}
- \item kretprobes can be registered the same way than regular probe but using
+ \item \code{kretprobes} can be registered the same way than regular probes but using
a \kstruct{kretprobe} with \kfunc{register_kretprobe}
\begin{itemize}
\item Provided handlers will be called on function entry and exit
@@ -94,7 +94,7 @@ register_kretprobe(&probe);
\begin{frame}
\frametitle{{\em perf}}
\begin{itemize}
- \item Perf allows to do a wide range of tracing and recording operations.
+ \item {\em perf} allows to do a wide range of tracing and recording operations.
\item The kernel already contains events and tracepoints that can be used.
The list is given using \code{perf list}.
\item Syscall tracepoints should be enabled in kernel configuration using
@@ -171,7 +171,7 @@ Overhead Command Shared Object Symbol
\begin{frame}
\frametitle{{\em perf probe}}
\begin{itemize}
- \item perf allows to create dynamic tracepoints on both kernel functions and
+ \item {\em perf} allows to create dynamic tracepoints on both kernel functions and
user-space functions.
\item In order to be able to insert probes, \kconfig{CONFIG_KPROBE} must be
enabled in the kernel.
@@ -181,7 +181,7 @@ Overhead Command Shared Object Symbol
\end{itemize}
\item New dynamic probes can be created and then used using
{\em perf record}.
- \item Often on embedded platform, \kconfig{vmlinux} is not present on the
+ \item Often on embedded platforms, \kconfig{vmlinux} is not present on the
target and thus only symbols and registers can be used.
\end{itemize}
\end{frame}
@@ -312,7 +312,7 @@ kworker/0:2-mm_ 44 [000] 208.620653: 133104 cycles: c0a44c84
\begin{frame}[fragile]
\frametitle{Using {\em perf top} }
\begin{itemize}
- \item \code{perf top} allows to do a live analysis of the running kernel
+ \item \code{perf top} allows to do a live analysis of the running kernel
\item It will sample all function calls and display them ordered by most
time consuming one.
\item This allows to profile the whole system usage
@@ -342,7 +342,7 @@ Overhead Shared Object Symbol
\begin{frame}
\frametitle{ftrace}
\begin{itemize}
- \item ftrace is a tracing framework within the kernel which stands for
+ \item {\em ftrace} is a tracing framework within the kernel which stands for
"Function Tracer".
\item It offers a wide range of tracing capabilities allowing to observe the
system behavior.
@@ -350,14 +350,14 @@ Overhead Shared Object Symbol
\item Trace static tracepoints already inserted in the kernel various
parts (scheduler, interrupts, etc).
\item Relies on GCC mcount() capability and kernel code patching mechanism
- to call ftrace tracing handlers.
+ to call {\em ftrace} tracing handlers.
\end{itemize}
\item All traces are recorded in a ring buffer that is optimized for tracing.
\item Uses {\em tracefs} filesystem to control and display tracing events.
\begin{itemize}
\item \codewithhash{\# mount -t tracefs nodev /sys/kernel/tracing}.
\end{itemize}
- \item ftrace support must be enabled in the kernel using
+ \item {\em ftrace} support must be enabled in the kernel using
\kconfigval{CONFIG_FTRACE}{y}.
\item \kconfig{CONFIG_DYNAMIC_FTRACE} allows to have a zero overhead tracing
support.
@@ -367,7 +367,7 @@ Overhead Shared Object Symbol
\begin{frame}
\frametitle{ftrace files}
\begin{itemize}
- \item ftrace control is exposed through some specific files located under
+ \item {\em ftrace} controls are exposed through some specific files located under
\code{/sys/kernel/tracing}.
\begin{itemize}
\item \code{current_tracer}: Current tracer that is used.
@@ -382,7 +382,7 @@ Overhead Shared Object Symbol
\item \code{set_graph_function}: Graph only the specified functions child.
\end{itemize}
\item Many other files are exposed, see \kdochtml{trace/ftrace.html}.
- \item {\em trace-cmd} CLI and {\em Kernelshark} GUI tools allows to record
+ \item {\em trace-cmd} CLI and {\em Kernelshark} GUI tools allow to record
and visualize tracing data more easily.
\end{itemize}
\end{frame}
@@ -390,14 +390,14 @@ Overhead Shared Object Symbol
\begin{frame}[fragile]
\frametitle{ftrace tracers}
\begin{itemize}
- \item ftrace provides several "tracers" which allow to trace different thing.
+ \item ftrace provides several "tracers" which allow to trace different things.
\item The tracer to be used should be written to the \code{current_tracer} file
\begin{itemize}
- \item \code{nop}: Trace nothing, use to disable all tracing.
+ \item \code{nop}: Trace nothing, used to disable all tracing.
\item \code{function}: Trace all kernel functions that are called.
- \item \code{function_graph}: Similar to {function} but traces both entry and exit.
+ \item \code{function_graph}: Similar to \code{function} but traces both entry and exit.
\item \code{hwlat}: Trace hardware latency.
- \item \code{irqsoff}: Trace interrupts disable sections.
+ \item \code{irqsoff}: Trace sections where interrupts are disabled.
\item \code{branch}: Trace likely()/unlikely() prediction errors.
\item \code{mmiotrace}: Trace all accesses to the hardware (\code{read[bwlq]/write[bwlq]}).
\end{itemize}
@@ -413,9 +413,9 @@ Overhead Shared Object Symbol
\begin{frame}[fragile]
\frametitle{{\em function\_graph} tracer report example}
\begin{itemize}
- \item The {\em function\_graph} traces all the function and their associated
- callgraph that executed will acquiring the trace.
- \item Will display the process, CPU, timestamp and function graph.
+ \item The {\em function\_graph} traces all the function that
+ executed and their associated callgraphs
+ \item Will display the process, CPU, timestamp and function graph:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\tiny]{console}
@@ -447,9 +447,8 @@ dd-113 [000] 304.526719: funcgraph_exit: + 18.083 us | }
\begin{itemize}
\item ftrace {\em irqsoff} tracer allows to trace the irqs latency due to
interrupts being disabled for too long.
- \item Helpful to find why interrupt have a high latency on a system.
- \item This tracer will record the longest trace leading to the interrupts
- being disabled.
+ \item Helpful to find why interrupts have high latencies on a system.
+ \item This tracer will record the longest trace with interrupts being disabled.
\item This tracer needs to be enabled with \kconfigval{IRQSOFF_TRACER}{y}.
\begin{itemize}
\item \code{preemptoff}, \code{premptirqsoff} tracers also exist to trace
@@ -494,11 +493,11 @@ stress-n-114 0d.s. 290us : <stack trace>
\begin{frame}
\frametitle{Hardware latency detector}
\begin{itemize}
- \item ftrace {\em hwlat} tracer will help to find if the hardware generate
+ \item ftrace {\em hwlat} tracer will help to find if the hardware generates
latency.
\begin{itemize}
\item Sytem Management interrupts for instance are non maskable and
- directly triggers some firmware support feature, suspending CPU execution.
+ directly trigger some firmware support feature, suspending CPU execution.
\item Interrupts handled by secure monitor can also cause this kind of
latency.
\end{itemize}
@@ -515,7 +514,7 @@ stress-n-114 0d.s. 290us : <stack trace>
\begin{frame}[fragile]
\frametitle{\kfunc{trace_printk}}
\begin{itemize}
- \item \kfunc{trace_printk} allow to emit string in the trace buffer
+ \item \kfunc{trace_printk} allows to emit strings in the trace buffer
\item Useful to trace some specific conditions in your code and display it in the trace buffer
\end{itemize}
\begin{block}{}
@@ -543,13 +542,13 @@ void read_hw()
\begin{frame}
\frametitle{{\em trace-cmd}}
\begin{itemize}
- \item {\em trace-cmd} is a tool written by Steven Rostedt which allow
- interacting with kernel ftrace support (\manpage{trace-cmd}{1}).
- \item The tracer supported by {\em trace-cmd} are those exposed by ftrace.
+ \item {\em trace-cmd} is a tool written by Steven Rostedt which allows
+ interacting with {\em ftrace} (\manpage{trace-cmd}{1}).
+ \item The tracers supported by {\em trace-cmd} are those exposed by ftrace.
\item {\em trace-cmd} offers multiple commands:
\begin{itemize}
- \item {\em list}: list available plugins/events that can be recorded
- \item {\em record}: record a trace into \code{trace.dat} file.
+ \item {\em list}: List available plugins/events that can be recorded.
+ \item {\em record}: Record a trace into the file \code{trace.dat}.
\item {\em report}: Display \code{trace.dat} acquisition results.
\end{itemize}
\end{itemize}
@@ -558,10 +557,10 @@ void read_hw()
\begin{frame}
\frametitle{Remote tracing with {\em trace-cmd}}
\begin{itemize}
- \item {\em trace-cmd} output can be quite big and thus difficult to be
- stored on an embedded platform with not much storage space.
- \item For that purpose, a listen command is available and allows sending
- the traces over network.
+ \item {\em trace-cmd} output can be quite big and thus difficult to
+ store on an embedded platform with limited storage.
+ \item For that purpose, a \code{listen} command is available and allows sending
+ the acquisitions over the network:
\begin{itemize}
\item Run \code{trace-cmd listen -p 6578} on the target system
\item On the remote system that will be collecting the traces, use
@@ -637,7 +636,7 @@ $ trace-cmd record -l spi_* -p function
\end{block}
\begin{itemize}
- \item Trace the dd command using the function graph tracer:
+ \item Trace the {\em dd} command using the function graph tracer:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\tiny]{console}
@@ -658,7 +657,7 @@ $ trace-cmd show
\begin{frame}[fragile]
\frametitle{{\em trace-cmd} examples (3/2)}
\begin{itemize}
- \item Reset all the ftrace buffers and remove tracers
+ \item Reset all the {\em ftrace} buffers and remove tracers
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\tiny]{console}
@@ -667,7 +666,7 @@ $ trace-cmd reset
\end{block}
\begin{itemize}
- \item Run the irqsoff tracers on the system:
+ \item Run the {\em irqsoff} tracer on the system:
\end{itemize}
\begin{block}{}
\begin{minted}[fontsize=\tiny]{console}
@@ -773,8 +772,8 @@ void any_func(void)
way (Added in kernel 3.15)
\item Execution is event-driven and can be hooked using Kprobes, tracepoints
and other methods of tracing
- \item Allow to execute complex actions and report data to userspace for
- events that take place in the kernel.
+ \item Executes complex actions and reports data to userspace for
+ events that took place in the kernel.
\item Used to hook into various places of the kernel: VFS, Network stack,
syscalls, load balancing, security, etc
\end{itemize}
@@ -796,10 +795,10 @@ void any_func(void)
\item Almost all architectures have a BPF JIT support which allows
translating the BPF format into native CPU instruction, thus being
(almost) as fast as natively compiled code
- \item BPF programs can returned value in maps of various types (hash tables,
+ \item BPF programs can return values in maps of various types (hash tables,
arrays, etc) which allows sharing data between user-space, eBPF
programs and kernel space.
- \item Only some function (called helpers) can be called in eBPF programs.
+ \item Only some functions (called helpers) can be called in eBPF programs.
\item eBPF programs are attached to events (invoked on trigger).
\end{itemize}
\end{frame}
@@ -807,7 +806,7 @@ void any_func(void)
\begin{frame}[fragile]
\frametitle{Writing eBPF programs}
\begin{itemize}
- \item eBPF programs can be written in (a restricted) C and are compiled
+ \item eBPF programs can be written in (restricted) C and are compiled
using clang compiler
\item BCC (BPF Compiler Collection) provides a toolkit to write BPF
programs more easily using C language (also provides LUA and Python
@@ -825,7 +824,7 @@ void any_func(void)
\begin{columns}
\column{0.75\textwidth}
\begin{itemize}
- \item BPF Compiler Collection (BCC) is (as its name suggest) a collection
+ \item BPF Compiler Collection (BCC) is (as its name suggests) a collection
of BPF based tools.
\item BCC provides a large number of ready-to-use tools written in BPF.
\item Also provides an interface to write, load and hook BPF programs more
@@ -885,7 +884,7 @@ PID COMM IP SADDR DADDR DPORT
\begin{itemize}
\item BCC python support allows to easily write and hook C program for BPF
tracing.
- \item Hook with a kprobe on the \code{clone()} system call and display \verb+"Hello, World!"+ each
+ \item Hook with a {\em kprobe} on the \code{clone()} system call and display \verb+"Hello, World!"+ each
time it is called
\end{itemize}
\begin{block}{}
@@ -912,8 +911,8 @@ b.attach_kprobe(event=b.get_syscall_fnname("clone"), fn_name="hello")
\column{0.75\textwidth}
\begin{itemize}
\item bpftrace is a high level tracing language allowing to write tracing
- expression easily (\url{https://bpftrace.org/})
- \item Also provide tools that allows tracing various part of the kernel
+ expressions easily (\url{https://bpftrace.org/})
+ \item Also provide tools to trace various parts of the kernel
\begin{itemize}
\item Internally uses LLVM to compile script and BCC to interact with the BPF programs
\end{itemize}
@@ -976,7 +975,7 @@ Attaching 1 probe...
\column{0.65\textwidth}
\begin{itemize}
\item LTTng is an open source tracing framework for Linux maintained by
- the \url{https://www.efficios.com/}{EfficiOS} company.
+ the \href{https://www.efficios.com/}{EfficiOS} company.
\item LTTng allows understanding the interactions between the kernel and
applications (C, C++, Java, Python).
\begin{itemize}
@@ -995,7 +994,7 @@ Attaching 1 probe...
\begin{frame}
\frametitle{{\em LTTng} (2/2)}
\begin{itemize}
- \item Uses the \url{https://diamon.org/ctf/}{CTF} trace format (Common
+ \item Uses the \href{https://diamon.org/ctf/}{CTF} trace format (Common
Trace Format).
\item LTTng is made of multiple components:
\begin{itemize}
@@ -1155,9 +1154,8 @@ $ babeltrace2 ./my_traces
\begin{frame}[fragile]
\frametitle{Remote tracing with {\em LTTng}}
\begin{itemize}
- \item LTTng allows to record traces over network.
- \item Useful for embedded systems that do not have a lot of storage
- immediatly available.
+ \item LTTng allows to record traces over the network.
+ \item Useful for embedded systems with limited storage capabilities.
\item On the remote computer, run \code{lttng-relayd} command
\end{itemize}
\begin{block}{}
More information about the training-materials-updates
mailing list