[bootlin/training-materials updates] master: debugging: slides: debugging-linux-application-stack: Fix some typos (a31f7925)
Herve Codina
herve.codina at bootlin.com
Mon Nov 14 18:21:04 CET 2022
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/a31f7925bab863490806a28c2db6eada65b9ce3c
>---------------------------------------------------------------
commit a31f7925bab863490806a28c2db6eada65b9ce3c
Author: Herve Codina <herve.codina at bootlin.com>
Date: Mon Nov 14 18:19:47 2022 +0100
debugging: slides: debugging-linux-application-stack: Fix some typos
Signed-off-by: Herve Codina <herve.codina at bootlin.com>
>---------------------------------------------------------------
a31f7925bab863490806a28c2db6eada65b9ce3c
.../debugging-linux-application-stack.tex | 34 +++++++++++-----------
1 file changed, 17 insertions(+), 17 deletions(-)
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 bb1061ac..92bb6f75 100644
--- a/slides/debugging-linux-application-stack/debugging-linux-application-stack.tex
+++ b/slides/debugging-linux-application-stack/debugging-linux-application-stack.tex
@@ -32,7 +32,7 @@
\item A special file named \code{/proc/self} accessible by the process
points to the proc folder associated to it.
\end{itemize}
- \item When starting a process, it initially have one execution thread that
+ \item When starting a process, it initially has one execution thread that
is represented by a \kstruct{task_struct} and that can be scheduled.
\begin{itemize}
\item A process is represented in the kernel by a thread associated to
@@ -70,7 +70,7 @@
that are accessed by the CPU are virtual
\item The Memory Management Unit allows to map these virtual addresses to
physical memory (either RAM or IO)
- \item All these mappings are inserted into the page table that is used the
+ \item All these mappings are inserted into the page table that is used by the
MMU hardware to translate the CPU access to virtual addresses
\item The MMU allows to restrict access to the page mappings via some
attributes
@@ -107,7 +107,7 @@
\begin{frame}
\frametitle{Userspace/Kernel memory layout}
- Multiple process have different user memory space
+ Multiple processes have different user memory space
\center\includegraphics[height=0.7\textheight]{slides/debugging-linux-application-stack/multiple_process.pdf}
\end{frame}
@@ -145,7 +145,7 @@
\item Execute data from a non-executable segment
\end{itemize}
\item New memory zones can be created using \code{mmap()}
- (\manpage{mmap}{2}))
+ (\manpage{mmap}{2})
\item Per application mappings are visible in {\em /proc/<pid>/maps}\\
\begin{minted}[fontsize=\small]{console}
7f1855b2a000-7f1855b2c000 rw-p 00030000 103:01 3408650 ld-2.33.so
@@ -230,8 +230,8 @@
\item This state change will end up in kernel entrypoint (often call vectors)
that will execute necessary code to setup a correct state for kernel
mode execution.
- \item The kernel take care of saving registers, switching to the kernel
- stack and potentially other thing depending on the architecture.
+ \item The kernel takes care of saving registers, switching to the kernel
+ stack and potentially other things depending on the architecture.
\begin{itemize}
\item Does not use the user stack but a specific kernel fixed size stack
for security purpose.
@@ -262,7 +262,7 @@
\begin{frame}
\frametitle{Interrupts}
\begin{itemize}
- \item Interrupts are asynchronous signals that are generated by he hardware
+ \item Interrupts are asynchronous signals that are generated by the hardware
peripherals.
\begin{itemize}
\item Can also be synchronous when generated using a specific instruction
@@ -293,7 +293,7 @@
\item When executing functions provided by the libc (\code{read()},
\code{write()}, etc), they often end up executing a system call.
\end{itemize}
- \item System call are identified by a numeric identifier that is passed
+ \item System calls are identified by a numeric identifier that is passed
via the registers.
\begin{itemize}
\item The kernel exports some defines (in \code {unistd.h}) that are named
@@ -315,7 +315,7 @@
identifiers and will invoke the correct handler after checking the
validity of the syscall.
\item System call parameters are passed via registers (up to 6).
- \item When executing this instruction the CPU will change it's execution
+ \item When executing this instruction the CPU will change its execution
state and switch to the kernel mode.
\item Each architecture uses a specific hardware mechanism
(\manpage{syscall}{2})
@@ -372,10 +372,10 @@ root 11 2 [rcu_tasks_kthread] TS
in the future
\item Workqueues are executing the work functions in kernel threads.
\begin{itemize}
- \item Allows to sleep while executed the defered work.
+ \item Allows to sleep while executing the defered work.
\item Interrupts are enabled while executing
\end{itemize}
- \item Work can be executing either in dedicated work queues or in the
+ \item Work can be executed either in dedicated work queues or in the
default workqueue that is shared by multiple users.
\end{itemize}
\end{frame}
@@ -421,13 +421,13 @@ root 11 2 [rcu_tasks_kthread] TS
\begin{frame}
\frametitle{Allocations and context}
\begin{itemize}
- \item Allocating memory in the kernel can be done using multiples functions:
+ \item Allocating memory in the kernel can be done using multiple functions:
\begin{itemize}
\item \mint{c}+void *kmalloc(size_t size, int flags);+
\item \mint{c}+void *kzalloc(size_t size, gfp_t flags);+
\item \mint{c}+unsigned long __get_free_pages(int flags, unsigned int order)+
\end{itemize}
- \item All allocation function take a flag parameters which allow to
+ \item All allocation functions take a flag parameters which allow to
designate the kind of memory that is needed.
\begin{itemize}
\item \kfunc{GFP_KERNEL}: Normal allocation, can sleep while allocating
@@ -444,7 +444,7 @@ root 11 2 [rcu_tasks_kthread] TS
\column{0.75\textwidth}
{\bf E}xecutable and {\bf L}inkable {\bf F}ormat
\begin{itemize}
- \item File starting with an header which holds binary structures
+ \item File starting with a header which holds binary structures
defining the file
\item Collection of segments and sections that contains data
\begin{itemize}
@@ -475,7 +475,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 debugguer to match addresses and symbols names, call
+ \item Allows the debugger to match addresses and symbols names, call
sites, etc
\item Debugging information are generated by GDB and are included in the
ELF file if compiled with \code{-g}
@@ -503,7 +503,7 @@ $ gcc -g file.c -o program
\begin{itemize}
\item \code{$1 = <value optimized out>}
\end{itemize}
- \item If one want to inspect variables and functions, it is possible to
+ \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}
@@ -529,7 +529,7 @@ $ gcc -g file.c -o program
\item Loaded at startup by \code{ld.so} (the dynamic loader)
\item Or at runtime using \code{dlopen()} from your code
\end{itemize}
- \item When starting a program (an ELF files actually), the kernel will
+ \item When starting a program (an ELF file actually), the kernel will
parse it and load the interpreter that needs to be invoked.
\begin{itemize}
\item Most of the time \code{PT_INTERP} program header of the ELF file is
More information about the training-materials-updates
mailing list