Reorganize floats and equations flow

report/report.tex

@@ -39,6 +39,8 @@ Under supervision of Francesco Zappa Nardelli, March -- August 2018\\
 %\renewcommand\theadgape{\Gape[4pt]}
 %\renewcommand\cellgape{\Gape[4pt]}
 
+\allowdisplaybreaks{}
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \begin{document}
@@ -271,6 +273,26 @@ IP of the current FDE if it was the last row. In particular, there can be no
 ``IP hole'' within a FDE --~unlike FDEs themselves, which can leave holes
 between them.
 
+For instance, the C source code in Listing~\ref{lst:ex1_c}, when compiled
+with \lstbash{gcc -O1 -fomit-frame-pointer -fno-stack-protector}, yields the
+assembly code in Listing~\ref{lst:ex1_asm}. The memory layout of the stack
+frame is presented in Table~\ref{table:ex1_stack_schema}, to help understanding
+how the stack frame is constructed. When interpreting the generated \ehframe{}
+with \lstbash{readelf -wF}, we obtain the (slightly edited)
+Listing~\ref{lst:ex1_dw}. During the function prelude, \ie{} for $\mhex{615}
+\leq \reg{rip} < \mhex{619}$, the stack frame only contains the return address,
+thus the CFA is 8 bytes above \reg{rsp}, and the return address is precisely at
+\reg{rsp} --~that is, stored between \reg{rsp} and $\reg{rsp} + 8$. Then, the
+contents of \lstc{fibo}, 8 integers of 4 bytes each, are allocated on the
+stack, which puts the CFA 32 bytes above \reg{rsp}; the return address still
+being 8 bytes below the CFA\@. The variable \lstc{pos} is optimized out in the
+generated assembly code, thus no stack space is allocated for it. Yet,
+\prog{gcc} decided to allocate a total space of 48 bytes for the stack frame
+for memory alignment reasons, which means subtracting 40 bytes to \reg{rsp}
+(address $\mhex{615}$ in the assembly). Then, by the end of the function, the
+local variables are discarded and \reg{rsp} is reset to its value from the
+first row.
+
 \begin{figure}[h]
     \begin{minipage}{0.45\textwidth}
         \lstinputlisting[language=C, firstline=3, lastline=12,
@@ -294,7 +316,7 @@ between them.
     \end{minipage}
 \end{figure}
 
-\begin{table}[h]
+\begin{table}[h!]
     \centering
     \begin{tabular}{|c|c|c|c|c|c}
         \stackfhead{+ \mhex{30}}
@@ -316,26 +338,6 @@ between them.
     \caption{Stack frame schema for fib7 (horizontal layout)}\label{table:ex1_stack_schema}
 \end{table}
 
-For instance, the C source code in Listing~\ref{lst:ex1_c}, when compiled
-with \lstbash{gcc -O1 -fomit-frame-pointer -fno-stack-protector}, yields the
-assembly code in Listing~\ref{lst:ex1_asm}. The memory layout of the stack
-frame is presented in Table~\ref{table:ex1_stack_schema}, to help understanding
-how the stack frame is constructed. When interpreting the generated \ehframe{}
-with \lstbash{readelf -wF}, we obtain the (slightly edited)
-Listing~\ref{lst:ex1_dw}. During the function prelude, \ie{} for $\mhex{615}
-\leq \reg{rip} < \mhex{619}$, the stack frame only contains the return address,
-thus the CFA is 8 bytes above \reg{rsp}, and the return address is precisely at
-\reg{rsp} --~that is, stored between \reg{rsp} and $\reg{rsp} + 8$. Then, the
-contents of \lstc{fibo}, 8 integers of 4 bytes each, are allocated on the
-stack, which puts the CFA 32 bytes above \reg{rsp}; the return address still
-being 8 bytes below the CFA\@. The variable \lstc{pos} is optimized out in the
-generated assembly code, thus no stack space is allocated for it. Yet,
-\prog{gcc} decided to allocate a total space of 48 bytes for the stack frame
-for memory alignment reasons, which means subtracting 40 bytes to \reg{rsp}
-(address $\mhex{615}$ in the assembly). Then, by the end of the function, the
-local variables are discarded and \reg{rsp} is reset to its value from the
-first row.
-
 However, DWARF data isn't actually stored as a table in the binary files, but
 is instead stored as in Listing~\ref{lst:ex1_dwraw}. The first row has the
 location of the first IP in the FDE, and must define at least its CFA\@. Then,
@@ -349,6 +351,8 @@ unwinding a frame from an IP close to the end of the frame will require
 evaluating pretty much every DWARF row in the table before reaching the
 relevant information, slowing down drastically the unwinding process.
 
+\FloatBarrier{}
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsection{How big are FDEs?}