Hi, I am collecting calls to C a function with the pid provider and I collect the parameters of each call (doing @a[arg0,arg1,arg2] = count();). One of the parameters (arg1) is a function pointer. So, I take the value I obtained and examine it with dbx. Dbx then prints the address as being myFunction+0x100. The function name is coherent with what I know about the program (i.e. it is very likely to be the right function that was referred to by the pointer). But why the offset ? Do function start 256 bytes after their symbol address ? Thanks a lot for all your help, -- Pierre-Olivier Gaillard On 9/13/07, Pierre-Olivier Gaillard <pierreolivier.gaillard at gmail.com> wrote:> > Thanks a lot. > > But if it does not use the debug registers, does it mean it modifies the > code on the fly to intercept the function call ? It looks like it from the > fbt documentation which is supposed to apply to pid too. > > I wonder if using the debug registers would be any faster. They would > cause lots of traps whereas the dtrace instrumentation might be very > efficient and just write some data that can be collected later. > > Thanks again, > > -- > Pierre-Olivier Gaillard > > On 9/13/07, Dan Mick <dan.mick at sun.com> wrote: > > > > Pierre-Olivier Gaillard wrote: > > > Hi, > > > > > > I was wondering if there was a dtrace provider that uses the debug > > > registers. > > > > No, but... > > > > > I would like to trace all call to one or two user functions > > > and gather a few statistics about the data they handle. > > > This seems like a job for dtrace but I could not figure out what > > > provider to use. > > > > ...the pid provider should do just fine. With a "test" directory in > > the current directory, containing an entry "bin": > > > > dtrace -n pid\$target::strlen:entry -c "ls test" > > dtrace: description ''pid$target::strlen:entry'' matched 2 probes > > bin > > dtrace: pid 4037 has exited > > CPU ID FUNCTION:NAME > > 0 74985 strlen:entry > > 0 74985 strlen:entry > > > > > > > Thank you for your help, > > > > > > Pierre-Olivier Gaillard > > > > > > On 8/17/07, *Nasser Nouri* <nasser.nouri at sun.com > > > <mailto:nasser.nouri at sun.com>> wrote: > > > > > > There is a new article in SDN web site: > > > > > > "Using DTrace to Demystify Watchpoints in the Sun Studio dbx > > Debugger" > > > > > > http://developers.sun.com/sunstudio/articles/demistify_watch_points.html > > > > > > > > __Nasser > > > > > > > > > -- > > > This message posted from opensolaris.org <http://opensolaris.org> > > > _______________________________________________ > > > dtrace-discuss mailing list > > > dtrace-discuss at opensolaris.org <mailto:dtrace-discuss at opensolaris.org > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > dtrace-discuss mailing list > > > dtrace-discuss at opensolaris.org > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070914/9c740ee2/attachment.html>
"Pierre-Olivier" == Pierre-Olivier Gaillard <pierreolivier.gaillard at gmail.com> writes: Pierre-Olivier> I am collecting calls to C a function with the pid Pierre-Olivier> provider and I collect the parameters of each call Pierre-Olivier> (doing @a[arg0,arg1,arg2] = count();). One of the Pierre-Olivier> parameters (arg1) is a function pointer. So, I take Pierre-Olivier> the value I obtained and examine it with dbx. Dbx Pierre-Olivier> then prints the address as being myFunction+0x100. Pierre-Olivier> The function name is coherent with what I know about Pierre-Olivier> the program (i.e. it is very likely to be the right Pierre-Olivier> function that was referred to by the pointer). Pierre-Olivier> But why the offset ? Do function start 256 bytes after Pierre-Olivier> their symbol address ? Could you supply some sample code that shows what you''re doing? That might help us help you. Thanks. -- Dave Marquardt Sun Microsystems, Inc. Austin, TX +1 512 401-1077 (SUN internal: x64077)
Not sure about the offset since I have not yet seen your testcase. However,
based on what you have described, I created a testcase and it seems both DTrace
and dbx print the correct address of the function pointer without any offset!
%cat ufunc.d
#!/usr/sbin/dtrace -s
pid$target:$1::entry
{
@func[probefunc, arg0, arg1] = count();
}
% cat b.c
#include <stdio.h>
int funcp(int i) {
i = 512;
return i;
}
int funca(int i, int (*funcp)(int)) {
int j, k;
j = i;
j++;
k = funcp(i);
return 0;
}
main() {
float f = 5.0f;
int i = 99;
funca(i, funcp);
i = 4;
}
%dtrace -s ufunc.d -c ./b.out b.out
dtrace: script ''ufunc.d'' matched 4 probes
dtrace: pid 4512 has exited
__fsr -2748792236224
0 1
funca 99
4197408 1
funcp 99
4197408 1
% dbx b.out
For information about new features see `help changes''
To remove this message, put `dbxenv suppress_startup_message 7.6'' in
your .dbxrc
Reading b.out
Reading ld.so.1
Reading libc.so.1
(dbx) stop in funca
(2) stop in funca
(dbx) run
Running: b.out
(process id 4518)
stopped in funca at line 8 in file "b.c"
8 j = i;
(dbx) p -flx 4197408
0x400c20
(dbx) p funcp
funcp = 0x400c20 = &funcp(int i)
(dbx) p funca
funca = &funca(int i, int (*funcp)(int)) at 0x400c50
(dbx) where
=>[1] funca(i = 99, funcp = 0x400c20 = &funcp(int i)), line 8 in
"b.c"
[2] main(), line 17 in "b.c"
(dbx) dis funca
0x0000000000400c50: funca : pushq %rbp
0x0000000000400c51: funca+0x0001: movq %rsp,%rbp
0x0000000000400c54: funca+0x0004: subq $0x0000000000000020,%rsp
0x0000000000400c58: funca+0x0008: movl %edi,0xfffffffffffffffc(%rbp)
0x0000000000400c5b: funca+0x000b: movq %rsi,0xfffffffffffffff0(%rbp)
0x0000000000400c5f: funca+0x000f: movl 0xfffffffffffffffc(%rbp),%eax
0x0000000000400c62: funca+0x0012: movl %eax,0xffffffffffffffe8(%rbp)
0x0000000000400c65: funca+0x0015: movl 0xffffffffffffffe8(%rbp),%eax
0x0000000000400c68: funca+0x0018: addl $0x0000000000000001,%eax
0x0000000000400c6b: funca+0x001b: movl %eax,0xffffffffffffffe8(%rbp)
(dbx) p -flx $rsi
$rsi = 0x400c20
(dbx) dis 0x400c20
0x0000000000400c20: funcp : pushq %rbp
0x0000000000400c21: funcp+0x0001: movq %rsp,%rbp
0x0000000000400c24: funcp+0x0004: subq $0x0000000000000020,%rsp
0x0000000000400c28: funcp+0x0008: movl %edi,0xfffffffffffffffc(%rbp)
0x0000000000400c2b: funcp+0x000b: movl
$0x0000000000000200,0xfffffffffffffffc(%rbp)
0x0000000000400c32: funcp+0x0012: movl 0xfffffffffffffffc(%rbp),%eax
0x0000000000400c35: funcp+0x0015: movl %eax,0xffffffffffffffec(%rbp)
0x0000000000400c38: funcp+0x0018: jmp funcp+0x20 [ 0x400c40, .+8
]
0x0000000000400c3a: funcp+0x001a: nop
0x0000000000400c3c: funcp+0x001c: jmp funcp+0x20 [ 0x400c40, .+4
]
(dbx)
--
This message posted from opensolaris.org
Pierre-Olivier Gaillard wrote:> Hi, > > I am collecting calls to C a function with the pid provider and I > collect the parameters of each call (doing @a[arg0,arg1,arg2] = count();). > One of the parameters (arg1) is a function pointer. So, I take the value > I obtained and examine it with dbx. > Dbx then prints the address as being myFunction+0x100. > The function name is coherent with what I know about the program (i.e. > it is very likely to be the right function that was referred to by the > pointer). > > But why the offset ? Do function start 256 bytes after their symbol > address ?Don''t know; that doesn''t make any sense. Can you reproduce with a small example?
The small example submitted by Nasser seems fine : (dbx) examine 67152 dbx: warning: unknown language, ''ansic'' assumed 0x00010650: funcp : 0x9de3bf98 So, there is no offset there with the compiler I am using (SUNWspro-6u2) . I will try again in the big program I was investigating. Thanks for helping, P.O. Gaillard On 9/14/07, Dan Mick <dan.mick at sun.com> wrote:> > Pierre-Olivier Gaillard wrote: > > Hi, > > > > I am collecting calls to C a function with the pid provider and I > > collect the parameters of each call (doing @a[arg0,arg1,arg2] > count();). > > One of the parameters (arg1) is a function pointer. So, I take the value > > I obtained and examine it with dbx. > > Dbx then prints the address as being myFunction+0x100. > > The function name is coherent with what I know about the program (i.e. > > it is very likely to be the right function that was referred to by the > > pointer). > > > > But why the offset ? Do function start 256 bytes after their symbol > > address ? > > Don''t know; that doesn''t make any sense. Can you reproduce with a small > example? >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070917/a28aa2cc/attachment.html>