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}
This internship explored the possibility to compile DWARF's stack unwinding
data directly into native assembly on the x86\_64 architecture. Instead of
parsing and interpreting at runtime the debug data, the stack unwinding data is
accessed as a function of a dynamically-loaded shared library.
data directly into native assembly on the x86\_64 architecture, in order to
provide fast access to the data at assembly level. This compilation process was
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
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
frame is way too fast to be benched on a few samples (around $10\,\mu s$ per
frame), and having a lot of samples is quite complex, since one must avoid
unwinding the same frame over and over again, which would only benchmark the
caching mechanism. The other problem is to distribute evenly the unwinding
measures across the various program positions, including directly into the
loaded libraries (\eg{} the \prog{libc}).
frame is way too fast to provide a reliable benchmarking on a few samples
(around $10\,\mu s$ per frame). Having a lot of samples is not easy, since one
must avoid unwinding the same frame over and over again, which would only
benchmark the caching mechanism. The other problem is to distribute evenly the
unwinding measures across the various program positions, including directly
into the loaded libraries (\eg{} the \prog{libc}).
The solution eventually chosen was to modify \prog{perf}, the standard
profiling program for Linux, in order to gather statistics and benchmarks of
its unwindings, and produce an alternative version of \prog{libunwind} using
the compiled debugging data, in order to interface it with \prog{perf},
allowing to benchmark \prog{perf} with both the standard stack unwinding data
and the alternative experimental compiled format. As a free and enjoyable
side-effect, the experimental unwinding data is perfectly interfaced with
\prog{libunwind}, and thus interfaceable at practically no cost with any
existing project using the \textit{de facto} standard library \prog{libunwind}.
its unwindings. Modifying \prog{perf} was an additional challenge that turned
out to be harder than expected, since the source code is pretty opaque to
someone who doesn't know the project well. This, in particular, required to
produce an alternative version of \prog{libunwind} interfaced with the compiled
debugging data.
% What is your solution to the question described in the last paragraph?
%