lorenz.stechauner/BSc-Thesis
1
0
Fork 0
Code Activity

thesis: Some more proofreading

Browse Source
This commit is contained in:
Lorenz Stechauner
2025-08-24 17:15:16 +02:00
parent 44c8b21c9b
commit f4e816d769
2 changed files with 10 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
thesis/src/02.intercept.tex
View File

@@ -66,7 +66,7 @@ It works similarly to \texttt{strace} (see \ref{subsec:strace}).
\cite{ltrace.1}
Listings~\ref{lst:main.c} and~\ref{lst:ltrace} illustrate what the output of \texttt{ltrace} looks like.
In contrast to the output of \texttt{strace} now only ``real'' calls to library functions are included in the output.
In contrast to the output of \texttt{strace}, now only ``real'' calls to library functions are included in the output.
Therefore, a lot less ``noise'' is generated (see omitted lines in Listing~\ref{lst:strace}).
Again, the function arguments are displayed in a ``pretty'' way.
This command uses so-called prototype functions~\cite{ltrace.conf.5} to format function arguments.
@@ -268,8 +268,7 @@ Example: \texttt{malloc(123)} (or \texttt{malloc(0x7B)}).
\subsection{Unspecific Pointers}\label{subsec:retrieving-unspecific-pointers}
Pointers with no further information known about (like \texttt{void *}) are essentially integers.
Therefore, they may be treated as such.
Pointers without additional type information (such as \texttt{void *}) can essentially be treated as integers.
Example: \texttt{free(0x55624164b2a0)}.
@@ -300,7 +299,7 @@ Example: \texttt{open(0x1234:"test.txt", 0102:|O\_CREAT|O\_RDWR|, 0644)}.
\subsection{Constants}\label{subsec:retrieving-constants}
For some functions constants are used.
These constants are typically used C macros in the source code.
These constants are typically implemented as C macros (\texttt{\#define}) in the source code.
This makes the source code more readable (and portable).
Constants are represented as an integer again followed by a colon, this time without any special characters to distinguish them from other types.
@@ -408,11 +407,11 @@ typedef struct {
\end{description}
\end{quote}
Using information from \texttt{Dl\_info}, it is possible to exactly determine the (shared) object from where the call came from (\texttt{dli\_fname}).
Using information from \texttt{Dl\_info}, it is possible to exactly determine the (shared) object where the call came from (\texttt{dli\_fname}).
Furthermore, it is possible to calculate the relative position inside this (shared) object using \texttt{dli\_fbase} and the return address itself.
Keep in mind that the return address may only be used as an estimation for the origin of the call.
Especially heavily optimized programs might use the same return address for functions in different code paths.
Optionally, a name of a ``symbol'' (function) may be retrieved from where the function call came from.
Optionally, a name of a ``symbol'' (function) may be retrieved, indicating where the function call came from.
\subsection{Source File and Line Number}\label{subsec:source-file-and-line-number}

6
thesis/src/06.conclusion.tex
View File

@@ -2,10 +2,14 @@
\chapter{Conclusion}\label{ch:conclusion}
This work presented \texttt{intercept.so}, a shared object file intended to be preloaded using \texttt{LD\_PRELOAD}, which may be used to intercept function calls on Linux systems.
Furthermore, a tool to use this shared object easier---the \texttt{intercept} Python program---was presented.
Furthermore, a supporting Python program, \texttt{intercept}, was presented to make the shared object easier to use.
By using preloading to hook or intercept function calls, the overhead and performance degradation remain negligible for the purpose of testing student submissions.
To make use of intercepted function calls, some techniques of automatic testing of simple C programs were discussed.
In addition, the work has shown that creating an automated testing tool for the Operating Systems course assignments is both feasible and practical.
The evaluation indicates that performance overhead is negligible and therefore not a hindrance to real-world use.
Finally, since the approach relies on standard and portable mechanisms, the solution can be considered future-proof and adaptable to other environments.
The source code of the programs developed in this work is attached below.
(Not all PDF viewers may open/download attachments.)