Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

Yue Chen
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

------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

Ivo Raisr


2015-09-08 1:35 GMT+02:00 Yue Chen <[hidden email]>:
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.

------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

Yue Chen
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 <[hidden email]> wrote:


2015-09-08 1:35 GMT+02:00 Yue Chen <[hidden email]>:
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.


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

Yue Chen
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 <[hidden email]> wrote:


2015-09-08 8:10 GMT+02:00 Yue Chen <[hidden email]>:
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.


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

Tom Hughes-2
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 ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

Yue Chen
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 <[hidden email]> 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 ([hidden email])
http://compton.nu/


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|

Re: Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

John Reiser
> 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.


------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users