m2-internship/report
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Correct §5

Browse source
This commit is contained in:
Théophile Bastian 2018-08-08 14:29:04 +02:00
parent 9e09921c2a
commit fbb68ba2cf
2 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
report/TODO
View file

@ -1,2 +1 @@
- Make consistant -ise / -ize (eg. optimize)
- Add references to all my repositories

29
report/report.tex
View file

@ -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.