Re: [Valgrind-developers] callpath collection in valgrind

[Niall D. <ndo...@bl...>]

> > Note that for non-x86/x86 callgrind's optimized callstack generator
> > isn't reliable.
> Is there a way to differentiate the (at instrumentation time or at
> runtime) the instructions which leads to this non reliability.
> Then for such instructions, a more reliable but slower technique could be 
> used
> (e.g. unwind information, see below).

Josef and Julian will know the answer to this, but essentially the problem is 
that it is very hard to (quickly) reconstruct what's going on precisely on ARM 
from just the stack alone.

> > There is scope to greatly improve valgrind's callstack generator in
> > general if we had an unwind table parser (see -funwind-tables in GCC).
> > libunwind has one, but it need libc which makes it unsuitable for 
> > valgrind.
> Not too sure how to understand the above: Valgrind today generates
> stacktraces using unwind information, see e.g. in coregrind
> pub_core_debuginfo.h, m_stacktrace.c and files in coregrind/m_debuginfo.

Correct, though not in callgrind nor cachegrind. It is rather slow and memory 
hungry though.

> > Also, Julian
> > has some ARM EXIDX unwind table parser code he can point you at if
> > you're interested.
> What is the difference between these unwind tables and the dwarf unwind
> tables ?

ARM EXIDX unwind tables are specified by the ARM ABI for C++ exception 
unwinds. They are not a dwarf format, though can be (slowly) converted into a 
subset of dwarf format which is what Julian's code does.

A native ARM EXIDX unwind table parser would very significantly improve stack 
backtrace performance on ARM valgrind, as well as making callgrind and 
cachegrind actually useful on ARM.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of 
BlackBerry Inc.