Re: [Valgrind-developers] How stack tracing works in Valgrind

[Pharaoh . <pha...@gm...>]

On Sat, Feb 21, 2009 at 12:47 AM, Stephen McCamant <sm...@cs...>wrote:

> >>>>> "P" == Pharaoh  <pha...@gm...> writes:
>
> P> Hello list,
> P> I am trying to learn how Valgrind works, by going through the code
> P> and trying out test cases out of interest. The tool reports stack
> P> traces for errors with function name etc. How does Valgrind do it?
> P> I mean, I don't see libbfd being used anywhere neither any glibc
> P> apis is used to collect the stack info. Also, how are the addresses
> P> converted to symbol names?
>
> P> Any pointers will be helpful.
>
> The Valgrind core support for stack traces (as used by Memcheck, etc.)
> works in roughly the same way as something like GDB does. At the time
> it wants to record/print a stack trace, it walks up the linked frames
> on the stack to getting calling addresses. Then it tries to translate
> each address into a function name (using the executable's ELF symbol
> table) and potentially also a source file and line number (using DWARF
> or stabs debugging information). The Valgrind code that does this is
> custom written, in part because there have historically been various
> obstacles to linking external libraries with Valgrind, and I think
> also just that's the style the main developers prefer.
>
> To look at the code in the core that supports this, see:
>
> coregrind/m_debuginfo/*
> coregrind/m_stacktrace.c
>
> Most Valgrind tools don't use the strategy of recording at runtime
> when each function starts and finishes: though this would sometimes be
> useful if the stack gets corrupted or the information needed for a
> backtrace is missing, it's tricky to get working robustly in the face
> of things like longjmp() and tail calls. But some tools do track calls
> and returns, such as Callgrind and the Fjalar and Flowcheck tools that
> I and our group at MIT worked on.
>
> http://groups.csail.mit.edu/pag/fjalar/
> http://people.csail.mit.edu/smcc/projects/secret-flow/
>
> Hope this helps,
>
>  -- Stephen
>


Yes, this was exactly the kind of details I was looking for. Thanks
everyone.

-Pharaoh.