S h i v wrote:
> Thanks a lot for the detailed response.
>
> On Tue, May 20, 2008 at 4:13 PM, Vladimir Marek <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>>> [1] Predicates in one-liners
>>> I would like to list the probe modules in my executable and then
>>> dynamically create a dscript to trace execution of those modules alone
>>> (by excluding the 3rd party and system libraries). I tried the below
>>> script without success. The conditional given in the predicate is not
>>> taking effect. Why is this so ?
>>> $ dtrace -ln 'pid$target::: /probemod!="libc.so.1"/ { printf("%s -----
>>> %s",probefunc, probename); } ' -p `pgrep a.out`
>> By using pid$target::: you already placed probe to every instruction in
>> the binary. And dtrace -l shows all of them. The condition /.../ is
>> evaluated when the probe is fired.
>>
>
> This is a useful piece of information. Does placing the probe itself
> have *any* overheads. For ex:
yes, there is - it's minimal, but it adds up. your option 1 means "enable
all entry points in the target process" (ie actually fire(!)) "and don't do
anyting if probefunc is funcy or funcz", whereas 2 fires only at three
entry points.
The difference is probably noticable.
you might consider 1a,
pid$target::func*:entry
/(probefunc != funcy) && (probefunc != funcz)/
{}
which, assuming you have only 5 functions matching the pattern "func*",
will cause 5 probes to fire and not do anything for 2 of those (and perform
the default action otherwise).
> If I have 5 probefunc funcv, funcw, funcx, funcy & funcz and I am
> interested in dtracing first 3, which in the below is a better,
> -----------------------------------
> Option 1:
> pid$target:::entry
> /(probefunc != funcy) && (probefunc != funcz)/
> {}
> -----------------------------------
> Option 2:
> pid$target::funcv:entry
> {}
>
> pid$target::funcw:entry
> {}
>
> pid$target::funcx:entry
> {}
> -----------------------------------
>
> This is considering that the actual applications may have a few
> hundred probemods and a few thousand probefuncs and I might be
> interested in a subset of the available ones.
>
>>> [2] Is there any means to get the arguments of a function dynamically?
>>> I would like to create dscripts automatically to trace the functions
>>> and if possible trace arguments as well (when I have access only to
>>> the binaries).
>> $ dtrace -n 'pid$target::strcmp:entry{trace(copyinstr(arg0));
>> trace(copyinstr(arg1))}' -c ls | tail
>>
> <snip>
>> pid$target::strcmp:entry - trace entry point of strcmp function (function
>> arguments are available in entry point)
>>
> <snip>
>> So basically I just dump first and second parameter of the strcmp
>> function.
>>
> <snip>
>
> The only difficulty I see is that I need to know the number of
> arguments and the type beforehand.
>
> I have a simple program as below:
> ----------------------------------------------------
> #include <stdio.h>
>
> int foo(int n)
> { bar(n*n); return 0; }
>
> int bar(int n) { return 0; }
>
> int main()
> {
> while (1)
> {
> foo(10); bar(10); sleep(2);
> }
> return 0;
> }
> ----------------------------------------------------
> I tried the below actions (in the return probe) without success:
>
> printf("arg = %d",(int) copyin(arg0,sizeof(int)));
> printf("arg = %d",(int) copyin(arg1,sizeof(int)));
>
> trace(copyinstr(arg0));
> trace(copyinstr(arg1));
> trace(copyin(arg0,4));
> trace(copyin(arg1,4));
you don't have to copyin() integers - integers are passed by value.
copyin() and friends is necessary for data that's passed by reference (ie
pointer) across the userland/kernel boundary.
what you're trying to do above basically amounts to dereferencing an
integer as a pointer to integer.
HTH
Michael
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
_______________________________________________
dtrace-discuss mailing list
[email protected]
