Re: [Valgrind-developers] Question about function interception in valgrind

[Lu M. <kin...@gm...>]

Hello Pḧilippe,

The following is what I understand about valgrind. Would you give me some
suggestion?

* Valgrind is just a launcher (stage 1). It detect whether the client is a
script or an executable. If client
  is the former, Valgrind would bring up interpreter to interpret the
client. Then use execv to replace the
  execution image with tool - memcheck (stage 2)

* Because memcheck is a fully static linked image. It use mmap to load
relevant *.so, which is used
  to construct function call redirection table - Spec and Active. To get
information about symbol and
  address, Valgrind use readelf.c to parse .dynsym tables of the client and
loaded *.so.

* When execution beginning, Valgrind use JIT to generate the redirected
function call. Take a simple
  example. The debug message "REDIR: 0x4eb6f40 (malloc) redirected to
0x4c2c6ba (malloc)" means
  Valgrind translate the original client function call "call
0x4eb6f40<malloc>" to "call 0x4c2c6ba
  <replace_malloc>"

* Valgrind didn't rely on ld-linux.so during function redirection. But it
still execute ld-linux.so on
  emulated CPU when the client need some symbol resolvation because of
dynamic linking.

I took a small experiment to get deep understanding of valgrind.

$ cat malloc.c
#include <stdlib.h>

int main() {
  char *p = (char*)malloc(sizeof(char));
  *(int*)p = 10;
  return 0;
}

$ gcc malloc.c

$ ./i-valgrind-3.8.1/bin/valgrind -v ./a.out
...
--12872-- REDIR: 0x4eb6f40 (malloc) redirected to 0x4c2c6ba (malloc)
...
==12872== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

Event the a.out is stripped (without .symtab, only remains .dynsym),
Valgrind still work. So I guess
Valgrind only rely on .dynsym table.

I also striped lib.so. However, Valgrind works well. So I thought Valgrind
didn't rely on .symtab table
anymore.

Thanks a lot

2013/3/12 Philippe Waroquiers <phi...@sk...>

> On Tue, 2013-03-12 at 02:46 +0800, Lu Mitnick wrote:
> > Hello Pḧilippe,
> >
> > I have took a look of the files you mentioned, not understanding how
> > Valgrind works very well.
> > In the following is a observation of me, please tell me if the
> > statement is wrong.
> >
> > * coregrind/m_redir implements the function lookup table used by
> > VG_(translate)
> >   (coregrind/m_translate.c), a function do translattion.
> Yes, the translation code (m_translate.c) will call m_redir.c
> function VG_(redir_do_lookup) to see if an address of a function
> has to be redirected. If yes, rather than translating the original
> function, it translates the replacement function.
>
>
> >
> > Besides, I have some questions. Would you mind to answer me?
> >
> > * Is memcheck/Valgrind applicable to static-linked binary?
> Valgrind will sort of work with statically linked binaries, except
> that the standard Valgrind and tool redirections will not work.
> So, for example, malloc will not be replaced.
> This is because redirection instructions are in a shared object.
> If the executable is statically linked, the preload of the valgrind
> shared object will not be done, and so no replacement of malloc,
> libc, ... will be done.
>
> > * How do valgrind catch malloc call during translation?
> >
> >   I am wondering how do Valgrind gather the information of malloc
> > address. So that it could
> >   change the call target address during translation
> > (redirection/wrapping). Especially in striped
> >   binary, there are fewer symbols. How do Valgrind do it? And which
> > source files should I take
> >   a look?
> Valgrind will not work if libc etc have no debug info.
> Some distributions are stripping their libc etc.
> In such a case, VAlgrind will refuse
> to start, and will indicate to install the debug info for the library.
>
> Philippe
>
>
>