Introduce Valgrind

manuscrit/60_staticdeps/20_dynamic.tex

@@ -1,3 +1,40 @@
-\section{A baseline: dynamic dependencies detection with Valgrind}
+\section{A baseline: dynamic dependencies detection with \valgrind{}}
 
+As we already saw, a dynamic analyzer, such as \gus{}, has direct access to
+the actual data dependencies occurring throughout an execution. While such
+analyzers are often too slow to use in practice, they can be used as a baseline
+to evaluate static alternatives.
 
+Due to its complexity, \gus{} is, however, ill-suited for the implementation of
+a simple experiment if one is not already familiar with its codebase. For this
+reason, we implement \depsim{}, a dynamic analysis tool based on top of
+\valgrind{}, whose goal is to report dependencies encountered at runtime.
+
+\subsection{Valgrind}
+
+Most low-level developers and computer scientists know
+\valgrind{}~\cite{tool:valgrind} as a memory
+analysis tool, reporting bad memory accesses, memory leaks and the like.
+However, this is only the \texttt{memcheck} tool built into \valgrind{}, while the
+whole program is actually a binary instrumentation framework.
+
+\valgrind{} supports a wide variety of platforms, including x86-64 and
+ARM. However, at the time of the writing, it supports AVX2, but does not yet
+support AVX-512 on x86-64~\cite{tool:valgrind_arch_support} ---~there is,
+however, ongoing work in that direction~\cite{valgrind_avx512}. While its
+documentation is seemingly sparse and not frequently maintained, its code
+is well-commented and readable, with interfaces cleanly exposed; thus, once one
+gets a good enough comprehension of how the project's code is structured, this
+lack of documentation is not problematic. \valgrind{} is also a free and
+open-source software, distributed under the GNU GPLv2 license.
+
+\medskip{}
+
+In order to instrument a binary file, \valgrind{} first lifts the original
+assembly code to an intermediate representation. The instrumentation tool is
+then able to modify this intermediate representation before passing it back to
+Valgrind, which will re-compile it to a native binary before running it.
+
+While this intermediate representation, called \vex{}, is convenient to
+instrument a binary, it may further be used as a way to obtain \emph{semantics}
+for some assembly code, independently of the Valgrind framework.

manuscrit/biblio/tools.bib

@@ -36,6 +36,22 @@
     year      = {2003},
 }
 
+@misc{tool:valgrind_arch_support,
+    title={Valgrind --- supported platforms},
+    author={{Valgrind developpers}},
+    howpublished={\url{https://valgrind.org/info/platforms.html}},
+    year=2023,
+    month=09,
+}
+
+@inproceedings{valgrind_avx512,
+    author  = {Volnina, Tanya},
+    title   = {Enable {AVX-512} instructions in Valgrind},
+    url     = {https://fosdem.org/2022/schedule/event/valgrind_avx512/},
+    year    = {2022},
+    publisher = {{FOSDEM}},
+}
+
 @techreport{tool:pluto,
     author = {Uday Bondhugula and J. Ramanujam and P.
               Sadayappan},

manuscrit/include/macros.tex

@@ -46,6 +46,9 @@
 \newcommand{\cesasme}{\texttt{CesASMe}}
 \newcommand{\benchsuitebb}{\texttt{benchsuite-bb}}
 \newcommand{\staticdeps}{\texttt{staticdeps}}
+\newcommand{\depsim}{\texttt{depsim}}
+\newcommand{\valgrind}{\texttt{valgrind}}
+\newcommand{\vex}{\texttt{VEX}}
 
 \newcommand{\gdb}{\texttt{gdb}}