For a simple example, just compare the results of ``strace date'' and ``valgrind --trace-syscalls=yes date'' on Linux.
E.g., it records syscalls only related to Valgrind, like sys_open ( 0x40244a0(/usr/local/lib/valgrind/vgpreload_core-amd64-linux.so) sys_open ( 0x40249d8(/usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so) It also has other different operations like memory/signal/file operations, sysctl, etc. How to tell which are extra ones caused by Valgrind, which are not? On Tue, Sep 8, 2015 at 3:41 AM, Tom Hughes <t...@compton.nu> wrote: > On 08/09/15 07:43, Yue Chen wrote: > > I mean the result from >> >> "valgrind --trace-syscalls=yes ./myprogram" VS "truss ./myprogram" >> are different; >> >> NOT >> "truss valgrind --trace-syscalls=yes ./program" VS "truss ./program". >> >> Can I modify some Valgrind source code to mark the syscalls issued from >> Valgrind itself? >> > > You're confused. The --trace-syscalls flag only shows system calls issued > by your program. The only thing that would show those issued by valgrind > itself is trussing valgrind, ie the first option in your second version. > > Many things might be influencing which system calls the C library uses to > implement a given library call however, and it may be that the environment > valgrind provides is different in some way that causes the library to make > a different choice. > > I really wouldn't worry too much if you see odd differences here, but if > you really want us to comment on possible reasons you will likely need to > provide concrete examples. > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ >
------------------------------------------------------------------------------
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
