Menu
▾
▴
valgrind-users
|
From: Yue C. <yc...@gm...> - 2015-09-07 23:36:17
|
Hi, I tried to use Valgrind syscall tracing utility on FreeBSD 10.1. I found that that the results of ``truss'' and ``valgrind --trace-syscalls=yes'' are a little different. For example, the result of Valgrind has extra syscalls like sys_sysctl, sys_fstatfs6 and [async]. Is it because Valgrind result contains the syscalls issued from the instrumentation code, or something else? Thanks. Best, Yue |
|
From: Ivo R. <ivo...@gm...> - 2015-09-08 06:04:46
|
2015-09-08 1:35 GMT+02:00 Yue Chen <yc...@gm...>: > I tried to use Valgrind syscall tracing utility on FreeBSD 10.1. I found > that that the results of ``truss'' and ``valgrind --trace-syscalls=yes'' > are a little different. For example, the result of Valgrind has extra > syscalls like sys_sysctl, sys_fstatfs6 and [async]. > Is it because Valgrind result contains the syscalls issued from the > instrumentation code, or something else? > Thanks. > Think of Valgrind as a virtual machine. Truss observes behaviour of the host (Valgrind itself) while --trace-syscalls traces behavior of the guest (your application). Valgrind syscall machinery intercepts all syscalls from the application and in general they are not mapped 1:1 to native ones. Some of these might be changed or intercepted completely. Valgrind will also issue syscalls on its own. I. |
|
From: Yue C. <yc...@gm...> - 2015-09-08 06:10:55
|
Any approach that can distinguish which syscalls are from the application, and which syscalls are from Valgrind itself? On Tue, Sep 8, 2015 at 2:04 AM, Ivo Raisr <ivo...@gm...> wrote: > > > 2015-09-08 1:35 GMT+02:00 Yue Chen <yc...@gm...>: > >> I tried to use Valgrind syscall tracing utility on FreeBSD 10.1. I found >> that that the results of ``truss'' and ``valgrind --trace-syscalls=yes'' >> are a little different. For example, the result of Valgrind has extra >> syscalls like sys_sysctl, sys_fstatfs6 and [async]. >> Is it because Valgrind result contains the syscalls issued from the >> instrumentation code, or something else? >> Thanks. >> > > Think of Valgrind as a virtual machine. > Truss observes behaviour of the host (Valgrind itself) while > --trace-syscalls traces behavior of the guest (your application). > Valgrind syscall machinery intercepts all syscalls from the application > and in general they are not mapped 1:1 to native ones. > Some of these might be changed or intercepted completely. > Valgrind will also issue syscalls on its own. > I. > |
|
From: Yue C. <yc...@gm...> - 2015-09-08 06:43:39
|
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? On Tue, Sep 8, 2015 at 2:30 AM, Ivo Raisr <ivo...@gm...> wrote: > > > 2015-09-08 8:10 GMT+02:00 Yue Chen <yc...@gm...>: > >> Any approach that can distinguish which syscalls are from the >> application, and which syscalls are from Valgrind itself? >> > > Based solely on 'truss' output, no. > I. > |
|
From: Tom H. <to...@co...> - 2015-09-08 07:41:54
|
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 (to...@co...) http://compton.nu/ |
|
From: Yue C. <yc...@gm...> - 2015-09-21 03:49:45
|
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 <to...@co...> 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 (to...@co...) > http://compton.nu/ > |
|
From: John R. <jr...@bi...> - 2015-09-21 12:54:39
|
> 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? A filename which contains "valgrind/vgpreload_<tool-name>-<arch-name>-<os-name>.so" gives a hint that syscalls (or calls to wrappers for syscalls) from such a file should be re-directed to the non-traced versions. Depending on the details of how the current non-interception operates, such re-direction could be done when processing pre-loaded libraries, or might require a dynamic check of the program counter for every syscall that is simulated. |
Thanks for helping keep SourceForge clean.
X