From fbb68ba2cfc1601e44f92b397c67d43c0fe45e79 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Th=C3=A9ophile=20Bastian?= Date: Wed, 8 Aug 2018 14:29:04 +0200 Subject: [PATCH] =?UTF-8?q?Correct=20=C2=A75?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- report/TODO | 1 - report/report.tex | 29 +++++++++++++++-------------- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/report/TODO b/report/TODO index 929274f..a95c8c7 100644 --- a/report/TODO +++ b/report/TODO @@ -1,2 +1 @@ -- Make consistant -ise / -ize (eg. optimize) - Add references to all my repositories diff --git a/report/report.tex b/report/report.tex index ee71bd6..4448691 100644 --- a/report/report.tex +++ b/report/report.tex @@ -1014,14 +1014,15 @@ Table~\ref{table:bench_time}. \caption{Time benchmarking on hackbench}\label{table:bench_time} \end{table} -The performance of \ehelfs{} is probably overestimated, since \ehelfs{} do not -handle all registers from the original DWARF file, and thus the -\prog{libunwind} version must perform more computation. However, this overhead, -although impossible to measure without first implementing supports for every -register, would probably not be that big, since most of the time is spent -finding the relevant row. Support for every DWARF instruction, however, would -not slow down at all the implementation, since every instruction would simply -be compiled to x86\_64 without affecting the already supported code. +The performance of \ehelfs{} is probably overestimated for a production-ready +version, since \ehelfs{} do not handle all registers from the original DWARF +file, and thus the \prog{libunwind} version must perform more computation. +However, this overhead, although impossible to measure without first +implementing supports for every register, would probably not be that big, since +most of the time is spent finding the relevant row. Support for every DWARF +instruction, however, would not slow down at all the implementation, since +every instruction would simply be compiled to x86\_64 without affecting the +already supported code. It is also worth noting that on the machine described in Section~\ref{ssec:bench_hw}, the compilation of the \ehelfs{} at a level of @@ -1176,13 +1177,13 @@ only concerned about the columns CFA, \reg{rip}, \reg{rsp}, \reg{rbp} and second row analyzes all the columns that were encountered, no matter whether supported or not. -The Table~\ref{table:instr_types} analyzes the proportion of each command -(\ie\ the formal way a register is set) for non-CFA columns in the sampled -data. For a brief explanation, \texttt{Offset} means stored at offset from CFA, +The Table~\ref{table:instr_types} analyzes the proportion of each command (\ie\ +the formal way a register is set) for non-CFA columns in the sampled data. For +a brief explanation, \texttt{Offset} means stored at offset from CFA, \texttt{Register} means the value from a machine register, \texttt{Expression} -means stored at the value of an expression, and the \texttt{Val\_} prefix means -that the value must not be dereferenced. Overall, it can be seen that -supporting \texttt{Offset} already means supporting the vast majority of +means stored at the address of an expression's result, and the \texttt{Val\_} +prefix means that the value must not be dereferenced. Overall, it can be seen +that supporting \texttt{Offset} already means supporting the vast majority of registers. The data gathered (not reproduced here) also suggests that supporting a few common expressions is enough to support most of them.