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

Make "your contribution" clearer

Browse source
This commit is contained in:
Théophile Bastian 2018-08-17 13:23:04 +02:00
parent 67b25ca038
commit 7c99d3056e
1 changed files with 18 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
report/fiche_synthese.tex
View file

@ -66,31 +66,32 @@ fine-tuned caching and optimized code to mitigate this problem.
\subsection*{Your contribution} \subsection*{Your contribution}
This internship explored the possibility to compile DWARF's stack unwinding This internship explored the possibility to compile DWARF's stack unwinding
data directly into native assembly on the x86\_64 architecture. Instead of data directly into native assembly on the x86\_64 architecture, in order to
parsing and interpreting at runtime the debug data, the stack unwinding data is provide fast access to the data at assembly level. This compilation process was
accessed as a function of a dynamically-loaded shared library. fully implemented and tested on complex, real-world examples. The integration
of compiled DWARF into existing, real-world projects have been made easy by
implementing an alternative version of the \textit{de facto} standard library
for this purpose, \prog{libunwind}.
Multiple approaches have been tried, in order to determine which compilation Multiple approaches have been tried, in order to determine which compilation
process leads to the best time/space trade-off. process leads to the best time/space trade-off.
Quite unexpectedly, the part that proved hardest of the project was finding a Unexpectedly, the part that proved hardest of the project was finding a
benchmarking protocol that was both relevant and reliable. Unwinding one single benchmarking protocol that was both relevant and reliable. Unwinding one single
frame is way too fast to be benched on a few samples (around $10\,\mu s$ per frame is way too fast to provide a reliable benchmarking on a few samples
frame), and having a lot of samples is quite complex, since one must avoid (around $10\,\mu s$ per frame). Having a lot of samples is not easy, since one
unwinding the same frame over and over again, which would only benchmark the must avoid unwinding the same frame over and over again, which would only
caching mechanism. The other problem is to distribute evenly the unwinding benchmark the caching mechanism. The other problem is to distribute evenly the
measures across the various program positions, including directly into the unwinding measures across the various program positions, including directly
loaded libraries (\eg{} the \prog{libc}). into the loaded libraries (\eg{} the \prog{libc}).
The solution eventually chosen was to modify \prog{perf}, the standard The solution eventually chosen was to modify \prog{perf}, the standard
profiling program for Linux, in order to gather statistics and benchmarks of profiling program for Linux, in order to gather statistics and benchmarks of
its unwindings, and produce an alternative version of \prog{libunwind} using its unwindings. Modifying \prog{perf} was an additional challenge that turned
the compiled debugging data, in order to interface it with \prog{perf}, out to be harder than expected, since the source code is pretty opaque to
allowing to benchmark \prog{perf} with both the standard stack unwinding data someone who doesn't know the project well. This, in particular, required to
and the alternative experimental compiled format. As a free and enjoyable produce an alternative version of \prog{libunwind} interfaced with the compiled
side-effect, the experimental unwinding data is perfectly interfaced with debugging data.
\prog{libunwind}, and thus interfaceable at practically no cost with any
existing project using the \textit{de facto} standard library \prog{libunwind}.
% What is your solution to the question described in the last paragraph? % What is your solution to the question described in the last paragraph?
% %