|
From: Pharaoh . <pha...@gm...> - 2009-02-20 18:54:46
|
Hello list, I am trying to learn how Valgrind works, by going through the code and trying out test cases out of interest. The tool reports stack traces for errors with function name etc. How does Valgrind do it? I mean, I don't see libbfd being used anywhere neither any glibc apis is used to collect the stack info. Also, how are the addresses converted to symbol names? Any pointers will be helpful. Regards, Pharaoh. |
|
From: Bart V. A. <bar...@gm...> - 2009-02-20 19:09:38
|
On Fri, Feb 20, 2009 at 7:54 PM, Pharaoh . <pha...@gm...> wrote: > > I am trying to learn how Valgrind works, by going through the code and > trying > out test cases out of interest. The tool reports stack traces for errors > with function > name etc. How does Valgrind do it? I mean, I don't see libbfd being used > anywhere > neither any glibc apis is used to collect the stack info. Also, how are the > addresses > converted to symbol names? Did you alread have a look at the papers listed on the following page: http://www.valgrind.org/docs/pubs.html ? Bart. |
|
From: Stephen M.
|
>>>>> "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 |
|
From: Pharaoh . <pha...@gm...> - 2009-02-21 17:36:51
|
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. |