|
From: Lu M. <kin...@gm...> - 2013-03-04 19:16:54
|
Hello everyone, I am new to valgrind and wanna to know the mechanism of function interception. Valgrind online documentation mentioned the function interception is implemented via dynamic loader(dlopen/dlsym). I am curious about whether the mechanism works well or not when the instrumented program is static linked. To get deeper understanding of the topic. Would somebody tell me which files is related so that I could take a look. Thanks a lot |
|
From: Philippe W. <phi...@sk...> - 2013-03-04 20:24:20
|
On Tue, 2013-03-05 at 03:16 +0800, Lu Mitnick wrote: > Hello everyone, > > > I am new to valgrind and wanna to know the mechanism of function > interception. Valgrind online documentation mentioned the function > interception is implemented via dynamic loader(dlopen/dlsym). I am > curious about whether the mechanism works well or not when the > instrumented program is static linked. You can intercept statically linked functions. I also think that the interception functions can also be part of the statically linked main executable. However, the tools and core Valgrind replacement definitions are in shared objects, which I believe are only properly handled if the dynamic loader is activated. For implementation, see include/pub_tool_redir.h, coregrind/pub_core_redir.h and coregrind/m_redir.c. Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-03-05 22:00:27
|
On Tue, 2013-03-05 at 03:16 +0800, Lu Mitnick wrote: > Hello everyone, > > > I am new to valgrind and wanna to know the mechanism of function > interception. Valgrind online documentation mentioned the function > interception is implemented via dynamic loader(dlopen/dlsym). I am > curious about whether the mechanism works well or not when the > instrumented program is static linked. You can do replacement of statically linked functions. See e.g. how --soname-synonyms=somalloc=NONE allows to do replacement of a statically linked malloc library. However, the "instructions" telling to Valgrind core to do the "standard" replacements are functions with special names which are in dynamically loaded objects. For example, the "instruction+code" to replace realloc for memcheck can be found by nm vgpreload_memcheck-x86-linux.so | grep realloc giving 000042b3 T _vgr10090ZU_VgSoSynsomalloc_realloc 000043af T _vgr10090ZU_libcZdsoZa_realloc Replacement is working in fully static executable. However, the "standard" valgrind replacements are not done, as e.g. the memcheck vgpreload_memcheck-x86-linux.so will not be loaded, because the dynamic loader will not be invoked. > To get deeper understanding of the topic. Would somebody tell me which > files is related so that I could take a look. Look in include/pub_tool_redir.h, coregrind/pub_core_redir.h and coregrind/m_redir.c You can also activate Valgrind trace(s) to see what is going on e.g. -v -v -v -d -d -d --trace-redir=yes for a lot of trace about everything + a lot of trace about the redirection. Pḧilippe |
|
From: Lu M. <kin...@gm...> - 2013-03-11 18:46:41
|
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.
Besides, I have some questions. Would you mind to answer me?
* Is memcheck/Valgrind applicable to static-linked binary?
$ cat malloc.c
#include <stdlib.h>
int main() {
char *p = (char *)malloc(sizeof(char));
*(int *)p = 55;
return 0;
}
$ gcc malloc.c -o malloc
$ ./i-valgrind-3.8.1/bin/valgrind --tool=memcheck ./malloc
==4101== Memcheck, a memory error detector
==4101== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4101== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4101== Command: ./malloc
==4101==
==4101== Invalid write of size 4
==4101== at 0x40050E: main (in /home/mitnick/Desktop/IIS/ASan/malloc)
==4101== Address 0x51f4040 is 0 bytes inside a block of size 1 alloc'd
==4101== at 0x4C2A2D4: malloc (vg_replace_malloc.c:271)
==4101== by 0x400505: main (in /home/mitnick/Desktop/IIS/ASan/malloc)
==4101==
==4101==
==4101== HEAP SUMMARY:
==4101== in use at exit: 1 bytes in 1 blocks
==4101== total heap usage: 1 allocs, 0 frees, 1 bytes allocated
==4101==
==4101== LEAK SUMMARY:
==4101== definitely lost: 1 bytes in 1 blocks
==4101== indirectly lost: 0 bytes in 0 blocks
==4101== possibly lost: 0 bytes in 0 blocks
==4101== still reachable: 0 bytes in 0 blocks
==4101== suppressed: 0 bytes in 0 blocks
==4101== Rerun with --leak-check=full to see details of leaked memory
==4101==
==4101== For counts of detected and suppressed errors, rerun with: -v
==4101== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Obviously, Valgrind do catch the memory access error of main. If we use
static-linking
instead, we could find out that Valgrind do not work.
$ gcc -static malloc.c -o malloc
$ ./i-valgrind-3.8.1/bin/valgrind --tool=memcheck ./malloc
==4126== Memcheck, a memory error detector
==4126== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4126== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4126== Command: ./malloc
==4126==
==4126== Conditional jump or move depends on uninitialised value(s)
==4126== at 0x410AE6: __linkin_atfork (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x403E43: ptmalloc_init.part.8 (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x407924: malloc_hook_ini (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x450C92: _dl_init_paths (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x4112A8: _dl_non_dynamic_init (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x411B22: __libc_init_first (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126== by 0x40129C: (below main) (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126==
==4126== Use of uninitialised value of size 8
==4126== at 0x401B9F: __run_exit_handlers (in
/home/mitnick/Desktop/IIS/ASan/malloc)
==4126==
==4126==
==4126== HEAP SUMMARY:
==4126== in use at exit: 0 bytes in 0 blocks
==4126== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4126==
==4126== All heap blocks were freed -- no leaks are possible
==4126==
==4126== For counts of detected and suppressed errors, rerun with: -v
==4126== Use --track-origins=yes to see where uninitialised values come
from
==4126== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
* 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?
Thanks a lot
2013/3/6 Philippe Waroquiers <phi...@sk...>
> On Tue, 2013-03-05 at 03:16 +0800, Lu Mitnick wrote:
> > Hello everyone,
> >
> >
> > I am new to valgrind and wanna to know the mechanism of function
> > interception. Valgrind online documentation mentioned the function
> > interception is implemented via dynamic loader(dlopen/dlsym). I am
> > curious about whether the mechanism works well or not when the
> > instrumented program is static linked.
> You can do replacement of statically linked
> functions. See e.g. how --soname-synonyms=somalloc=NONE allows
> to do replacement of a statically linked malloc library.
>
> However, the "instructions" telling to Valgrind core to do the
> "standard" replacements are functions with special names which are
> in dynamically loaded objects.
> For example, the "instruction+code" to replace realloc for memcheck
> can be found by
> nm vgpreload_memcheck-x86-linux.so | grep realloc
> giving
> 000042b3 T _vgr10090ZU_VgSoSynsomalloc_realloc
> 000043af T _vgr10090ZU_libcZdsoZa_realloc
>
> Replacement is working in fully static executable.
> However, the "standard" valgrind replacements are not done,
> as e.g. the memcheck vgpreload_memcheck-x86-linux.so will not be loaded,
> because the dynamic loader will not be invoked.
>
> > To get deeper understanding of the topic. Would somebody tell me which
> > files is related so that I could take a look.
> Look in include/pub_tool_redir.h, coregrind/pub_core_redir.h
> and coregrind/m_redir.c
>
> You can also activate Valgrind trace(s) to see what is going on
> e.g. -v -v -v -d -d -d --trace-redir=yes
> for a lot of trace about everything + a lot of trace about the
> redirection.
>
> Pḧilippe
>
>
>
>
>
|
|
From: Philippe W. <phi...@sk...> - 2013-03-11 22:08:20
|
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 |
|
From: Lu M. <kin...@gm...> - 2013-03-23 22:37:53
|
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
>
>
>
|
|
From: Philippe W. <phi...@sk...> - 2013-03-24 17:47:19
|
On Sun, 2013-03-24 at 06:37 +0800, Lu Mitnick wrote:
I think the below is basically ok. However, I do not think that Valgrind
is mmap the .so : it relies on LD_PRELOAD and the dynamic loader to load
e.g. the redirection .so
Philippe
> 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
>
>
>
>
|