zhihui Chen
2009-Apr-22 13:56 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
I have found that pid provider can not create memcpy:return probe for
64bit process on snv_110. For example, the pid is 10603, I will have
following output for dtrace command:
#dtrace -n pid10603:libc.so.1:memcpy:return
dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return:
probe description pid10603:libc.so.1:memcpy:return does not match any probes
This just happens for 64bit process, 32bit process has no such a issue.
Following is dtrace output for 32bit-process
# dtrace -n pid403:libc.so.1:memcpy:return
dtrace: description ''pid403:libc.so.1:memcpy:return''
matched 1 probe
^C
Disable shows that 64bit memcpy function has many branches for ret
instructions:
# mdb -p 10603
Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ]
> memcpy::dis ! grep ret
libc.so.1`memcpy+0x5a0: ret
libc.so.1`memcpy+0x631: ret
libc.so.1`memcpy+0x6c2: ret
libc.so.1`memcpy+0x75b: ret
libc.so.1`memcpy+0x7e0: ret
libc.so.1`memcpy+0x879: ret
libc.so.1`memcpy+0x90a: ret
libc.so.1`memcpy+0x9a3: ret
libc.so.1`memcpy+0x1a6c: ret
I dont know whether there is any limitation for dtrace to create
user-level return probe. Does anyone can help explain this and provide a
solution?
Thanks
Zhihi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20090422/ae558e1b/attachment.html>
Jon Haslam
2009-Apr-22 20:12 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
Hi Zhihi,
This could be owing to the fact that there we''ve found jump
tables in the instructions. If DTrace finds jump tables when
attempting to create probes it goes into an ultra conservative
mode of operation.
To see if this is the problem, set the DTRACE_DEBUG environment
variable before invoking dtrace(1M). Here''s what I see on an snv_114
based system when I try to do what you''re doing:
# pflags 28997 | grep model
data model = _LP64 flags = MSACCT|MSFORK
# DTRACE_DEBUG=1 dtrace -n pid28997:libc:memcpy:return
<chop>
libdtrace DEBUG: libc.so.1 stret 0 0 0 0
libdtrace DEBUG: creating probe pid28997:libc.so.1:memcpy:return
libdtrace DEBUG: found a suspected jump table at memcpy:2e
dtrace: invalid probe specifier pid28997:libc:memcpy:return: probe
description pid28997:libc.so.1:memcpy:return does not match any probes
libdtrace DEBUG: abandoning pid 28997
There''s not a whole lot you can do about it.
Jon.
> I have found that pid provider can not create memcpy:return probe
> for 64bit process on snv_110. For example, the pid is 10603, I will
> have following output for dtrace command:
> #dtrace -n pid10603:libc.so.1:memcpy:return
> dtrace: invalid probe specifier
> pid10603:libc.so.1:memcpy:return: probe description
> pid10603:libc.so.1:memcpy:return does not match any probes
>
> This just happens for 64bit process, 32bit process has no such a
> issue. Following is dtrace output for 32bit-process
> # dtrace -n pid403:libc.so.1:memcpy:return
> dtrace: description
''pid403:libc.so.1:memcpy:return'' matched 1
> probe
> ^C
> Disable shows that 64bit memcpy function has many branches for ret
> instructions:
> # mdb -p 10603
> Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ]
> > memcpy::dis ! grep ret
> libc.so.1`memcpy+0x5a0: ret
> libc.so.1`memcpy+0x631: ret
> libc.so.1`memcpy+0x6c2: ret
> libc.so.1`memcpy+0x75b: ret
> libc.so.1`memcpy+0x7e0: ret
> libc.so.1`memcpy+0x879: ret
> libc.so.1`memcpy+0x90a: ret
> libc.so.1`memcpy+0x9a3: ret
> libc.so.1`memcpy+0x1a6c: ret
> I dont know whether there is any limitation for dtrace to create
> user-level return probe. Does anyone can help explain this and provide
> a solution?
>
>
> Thanks
> Zhihi
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
zhihui Chen
2009-Apr-23 01:54 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
Thanks a lot. How Dtrace know whether one function has jump tables? We have written some optimized functions for libc.so.1 and met this issue also, maybe we should try to avoid this. Thanks Zhihui 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com>> Hi Zhihi, > > This could be owing to the fact that there we''ve found jump > tables in the instructions. If DTrace finds jump tables when > attempting to create probes it goes into an ultra conservative > mode of operation. > > To see if this is the problem, set the DTRACE_DEBUG environment > variable before invoking dtrace(1M). Here''s what I see on an snv_114 > based system when I try to do what you''re doing: > > > # pflags 28997 | grep model > data model = _LP64 flags = MSACCT|MSFORK > # DTRACE_DEBUG=1 dtrace -n pid28997:libc:memcpy:return > <chop> > libdtrace DEBUG: libc.so.1 stret 0 0 0 0 > libdtrace DEBUG: creating probe pid28997:libc.so.1:memcpy:return > libdtrace DEBUG: found a suspected jump table at memcpy:2e > dtrace: invalid probe specifier pid28997:libc:memcpy:return: probe > description pid28997:libc.so.1:memcpy:return does not match any probes > libdtrace DEBUG: abandoning pid 28997 > > There''s not a whole lot you can do about it. > > Jon. > > I have found that pid provider can not create memcpy:return probe for >> 64bit process on snv_110. For example, the pid is 10603, I will have >> following output for dtrace command: >> #dtrace -n pid10603:libc.so.1:memcpy:return >> dtrace: invalid probe specifier pid10603:libc.so.1:memcpy:return: >> probe description pid10603:libc.so.1:memcpy:return does not match any probes >> This just happens for 64bit process, 32bit process has no such a >> issue. Following is dtrace output for 32bit-process >> # dtrace -n pid403:libc.so.1:memcpy:return >> dtrace: description ''pid403:libc.so.1:memcpy:return'' matched 1 >> probe >> ^C >> Disable shows that 64bit memcpy function has many branches for ret >> instructions: # mdb -p 10603 >> Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ] >> > memcpy::dis ! grep ret >> libc.so.1`memcpy+0x5a0: ret >> libc.so.1`memcpy+0x631: ret >> libc.so.1`memcpy+0x6c2: ret >> libc.so.1`memcpy+0x75b: ret >> libc.so.1`memcpy+0x7e0: ret >> libc.so.1`memcpy+0x879: ret >> libc.so.1`memcpy+0x90a: ret >> libc.so.1`memcpy+0x9a3: ret >> libc.so.1`memcpy+0x1a6c: ret >> I dont know whether there is any limitation for dtrace to create >> user-level return probe. Does anyone can help explain this and provide a >> solution? >> Thanks >> Zhihi >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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/20090423/6e392a3e/attachment.html>
Jon Haslam
2009-Apr-23 06:30 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
> Thanks a lot. How Dtrace know whether one function has jump tables? We > have written some optimized functions for libc.so.1 and met this issue > also, maybe we should try to avoid this.Take a look at dt_pid_has_jump_table() to see how it''s done: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/i386/dt_isadep.c#78 Jon.> > Thanks > Zhihui > > > 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com > <mailto:Jonathan.Haslam at sun.com>> > > Hi Zhihi, > > This could be owing to the fact that there we''ve found jump > tables in the instructions. If DTrace finds jump tables when > attempting to create probes it goes into an ultra conservative > mode of operation. > > To see if this is the problem, set the DTRACE_DEBUG environment > variable before invoking dtrace(1M). Here''s what I see on an snv_114 > based system when I try to do what you''re doing: > > > # pflags 28997 | grep model > data model = _LP64 flags = MSACCT|MSFORK > # DTRACE_DEBUG=1 dtrace -n pid28997:libc:memcpy:return > <chop> > libdtrace DEBUG: libc.so.1 stret 0 0 0 0 > libdtrace DEBUG: creating probe pid28997:libc.so.1:memcpy:return > libdtrace DEBUG: found a suspected jump table at memcpy:2e > dtrace: invalid probe specifier pid28997:libc:memcpy:return: probe > description pid28997:libc.so.1:memcpy:return does not match any probes > libdtrace DEBUG: abandoning pid 28997 > > There''s not a whole lot you can do about it. > > Jon. > > I have found that pid provider can not create > memcpy:return probe for 64bit process on snv_110. For example, > the pid is 10603, I will have following output for dtrace command: > #dtrace -n pid10603:libc.so.1:memcpy:return > dtrace: invalid probe specifier > pid10603:libc.so.1:memcpy:return: probe description > pid10603:libc.so.1:memcpy:return does not match any probes > This just happens for 64bit process, 32bit process > has no such a issue. Following is dtrace output for 32bit-process > # dtrace -n pid403:libc.so.1:memcpy:return > dtrace: description ''pid403:libc.so.1:memcpy:return'' > matched 1 probe > ^C > Disable shows that 64bit memcpy function has many branches > for ret instructions: # mdb -p 10603 > Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ] > > memcpy::dis ! grep ret > libc.so.1`memcpy+0x5a0: ret > libc.so.1`memcpy+0x631: ret > libc.so.1`memcpy+0x6c2: ret > libc.so.1`memcpy+0x75b: ret > libc.so.1`memcpy+0x7e0: ret > libc.so.1`memcpy+0x879: ret > libc.so.1`memcpy+0x90a: ret > libc.so.1`memcpy+0x9a3: ret > libc.so.1`memcpy+0x1a6c: ret > I dont know whether there is any limitation for dtrace to > create user-level return probe. Does anyone can help explain > this and provide a solution? > Thanks > Zhihi > ------------------------------------------------------------------------ > > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org > <mailto:dtrace-discuss at opensolaris.org> > > > >
zhihui Chen
2009-Apr-23 07:37 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
With my understanding, jump table is used to transfer program control from one place to another place, but pid provider just replace "ret" instruction with "int $0x3" to generate return probe for user-level function, what is the conflict between jump table and return probe? Of course, jump table may lead to that return probe would never fire, but any other reason? Thanks Zhihui 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com>> > Thanks a lot. How Dtrace know whether one function has jump tables? We >> have written some optimized functions for libc.so.1 and met this issue also, >> maybe we should try to avoid this. >> > > Take a look at dt_pid_has_jump_table() to see how it''s done: > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/i386/dt_isadep.c#78 > > Jon. > > >> Thanks >> Zhihui >> >> >> 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com <mailto: >> Jonathan.Haslam at sun.com>> >> >> >> Hi Zhihi, >> >> This could be owing to the fact that there we''ve found jump >> tables in the instructions. If DTrace finds jump tables when >> attempting to create probes it goes into an ultra conservative >> mode of operation. >> >> To see if this is the problem, set the DTRACE_DEBUG environment >> variable before invoking dtrace(1M). Here''s what I see on an snv_114 >> based system when I try to do what you''re doing: >> >> >> # pflags 28997 | grep model >> data model = _LP64 flags = MSACCT|MSFORK >> # DTRACE_DEBUG=1 dtrace -n pid28997:libc:memcpy:return >> <chop> >> libdtrace DEBUG: libc.so.1 stret 0 0 0 0 >> libdtrace DEBUG: creating probe pid28997:libc.so.1:memcpy:return >> libdtrace DEBUG: found a suspected jump table at memcpy:2e >> dtrace: invalid probe specifier pid28997:libc:memcpy:return: probe >> description pid28997:libc.so.1:memcpy:return does not match any probes >> libdtrace DEBUG: abandoning pid 28997 >> >> There''s not a whole lot you can do about it. >> >> Jon. >> >> I have found that pid provider can not create >> memcpy:return probe for 64bit process on snv_110. For example, >> the pid is 10603, I will have following output for dtrace command: >> #dtrace -n pid10603:libc.so.1:memcpy:return >> dtrace: invalid probe specifier >> pid10603:libc.so.1:memcpy:return: probe description >> pid10603:libc.so.1:memcpy:return does not match any probes >> This just happens for 64bit process, 32bit process >> has no such a issue. Following is dtrace output for 32bit-process >> # dtrace -n pid403:libc.so.1:memcpy:return >> dtrace: description ''pid403:libc.so.1:memcpy:return'' >> matched 1 probe >> ^C >> Disable shows that 64bit memcpy function has many branches >> for ret instructions: # mdb -p 10603 >> Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ] >> > memcpy::dis ! grep ret >> libc.so.1`memcpy+0x5a0: ret >> libc.so.1`memcpy+0x631: ret >> libc.so.1`memcpy+0x6c2: ret >> libc.so.1`memcpy+0x75b: ret >> libc.so.1`memcpy+0x7e0: ret >> libc.so.1`memcpy+0x879: ret >> libc.so.1`memcpy+0x90a: ret >> libc.so.1`memcpy+0x9a3: ret >> libc.so.1`memcpy+0x1a6c: ret >> I dont know whether there is any limitation for dtrace to >> create user-level return probe. Does anyone can help explain >> this and provide a solution? >> Thanks >> Zhihi >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >> <mailto:dtrace-discuss at opensolaris.org> >> >> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20090423/ed4e05fe/attachment.html>
Adam Leventhal
2009-Apr-24 02:36 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
Hi Zhihui, A jump table is used for a dense flow control redirection like you might find with a switch statement. The issue that it creates is that many compilers elect to mix data with code in such a way that prevents us from safely instrumenting it for fear or clobbering data. If you send out the full disassembly for the function in question we may be able to update the heuristics DTrace uses to identify the return site. Adam On Thu, Apr 23, 2009 at 03:37:28PM +0800, zhihui Chen wrote:> With my understanding, jump table is used to transfer program control from > one place to another place, but pid provider just replace "ret" instruction > with "int $0x3" to generate return probe for user-level function, what is > the conflict between jump table and return probe? Of course, jump table may > lead to that return probe would never fire, but any other reason? > Thanks > Zhihui > > 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com> > > > > > Thanks a lot. How Dtrace know whether one function has jump tables? We > >> have written some optimized functions for libc.so.1 and met this issue also, > >> maybe we should try to avoid this. > >> > > > > Take a look at dt_pid_has_jump_table() to see how it''s done: > > > > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/i386/dt_isadep.c#78 > > > > Jon. > > > > > >> Thanks > >> Zhihui > >> > >> > >> 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com <mailto: > >> Jonathan.Haslam at sun.com>> > >> > >> > >> Hi Zhihi, > >> > >> This could be owing to the fact that there we''ve found jump > >> tables in the instructions. If DTrace finds jump tables when > >> attempting to create probes it goes into an ultra conservative > >> mode of operation. > >> > >> To see if this is the problem, set the DTRACE_DEBUG environment > >> variable before invoking dtrace(1M). Here''s what I see on an snv_114 > >> based system when I try to do what you''re doing: > >> > >> > >> # pflags 28997 | grep model > >> data model = _LP64 flags = MSACCT|MSFORK > >> # DTRACE_DEBUG=1 dtrace -n pid28997:libc:memcpy:return > >> <chop> > >> libdtrace DEBUG: libc.so.1 stret 0 0 0 0 > >> libdtrace DEBUG: creating probe pid28997:libc.so.1:memcpy:return > >> libdtrace DEBUG: found a suspected jump table at memcpy:2e > >> dtrace: invalid probe specifier pid28997:libc:memcpy:return: probe > >> description pid28997:libc.so.1:memcpy:return does not match any probes > >> libdtrace DEBUG: abandoning pid 28997 > >> > >> There''s not a whole lot you can do about it. > >> > >> Jon. > >> > >> I have found that pid provider can not create > >> memcpy:return probe for 64bit process on snv_110. For example, > >> the pid is 10603, I will have following output for dtrace command: > >> #dtrace -n pid10603:libc.so.1:memcpy:return > >> dtrace: invalid probe specifier > >> pid10603:libc.so.1:memcpy:return: probe description > >> pid10603:libc.so.1:memcpy:return does not match any probes > >> This just happens for 64bit process, 32bit process > >> has no such a issue. Following is dtrace output for 32bit-process > >> # dtrace -n pid403:libc.so.1:memcpy:return > >> dtrace: description ''pid403:libc.so.1:memcpy:return'' > >> matched 1 probe > >> ^C > >> Disable shows that 64bit memcpy function has many branches > >> for ret instructions: # mdb -p 10603 > >> Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ] > >> > memcpy::dis ! grep ret > >> libc.so.1`memcpy+0x5a0: ret > >> libc.so.1`memcpy+0x631: ret > >> libc.so.1`memcpy+0x6c2: ret > >> libc.so.1`memcpy+0x75b: ret > >> libc.so.1`memcpy+0x7e0: ret > >> libc.so.1`memcpy+0x879: ret > >> libc.so.1`memcpy+0x90a: ret > >> libc.so.1`memcpy+0x9a3: ret > >> libc.so.1`memcpy+0x1a6c: ret > >> I dont know whether there is any limitation for dtrace to > >> create user-level return probe. Does anyone can help explain > >> this and provide a solution? > >> Thanks > >> Zhihi > >> > >> ------------------------------------------------------------------------ > >> > >> > >> > >> _______________________________________________ > >> dtrace-discuss mailing list > >> dtrace-discuss at opensolaris.org > >> <mailto:dtrace-discuss at opensolaris.org> > >> > >> > >> > >> > >> _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl
zhihui Chen
2009-Apr-24 03:01 UTC
[dtrace-discuss] PID provider can not create memcpy:return probe for 64bit process
Thanks, the full disassembly for memcpy can be easily found on any X86-64 platform with snv_110 or later using mdb and jump stable is found on the address like memcpy+0x2e by pid provider. client08-1# mdb /lib/amd64/libc.so.1 Loading modules: [ libc.so.1 ]> memcpy::dismemcpy: movq %rdx,%r8 memcpy+3: movq %rdi,%rcx memcpy+6: movq %rsi,%rdx memcpy+9: movq %rdi,%rax memcpy+0xc: leaq +0x4d(%rip),%r11 <memcpy+0x60> memcpy+0x13: cmpq $0x80,%r8 memcpy+0x1a: jg +0x990 <memcpy+0x9b0> memcpy+0x20: addq %r8,%rcx memcpy+0x23: addq %r8,%rdx memcpy+0x26: movslq (%r11,%r8,4),%r10 memcpy+0x2a: leaq (%r10,%r11),%r11 memcpy+0x2e: jmp *%r11 memcpy+0x31: nop memcpy+0x35: nop memcpy+0x39: nop memcpy+0x3d: nop memcpy+0x40: leaq +0x229(%rip),%r11 <memcpy+0x270> memcpy+0x47: movq %rcx,%r9 memcpy+0x4a: andq $0xf,%r9 memcpy+0x4e: movslq (%r11,%r9,4),%r10 ........ Zhihui 2009/4/24 Adam Leventhal <ahl at eng.sun.com>> Hi Zhihui, > > A jump table is used for a dense flow control redirection like you might > find with a switch statement. The issue that it creates is that many > compilers > elect to mix data with code in such a way that prevents us from safely > instrumenting it for fear or clobbering data. > > If you send out the full disassembly for the function in question we may be > able to update the heuristics DTrace uses to identify the return site. > > Adam > > On Thu, Apr 23, 2009 at 03:37:28PM +0800, zhihui Chen wrote: > > With my understanding, jump table is used to transfer program control > from > > one place to another place, but pid provider just replace "ret" > instruction > > with "int $0x3" to generate return probe for user-level function, what is > > the conflict between jump table and return probe? Of course, jump table > may > > lead to that return probe would never fire, but any other reason? > > Thanks > > Zhihui > > > > 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com> > > > > > > > > Thanks a lot. How Dtrace know whether one function has jump tables? We > > >> have written some optimized functions for libc.so.1 and met this issue > also, > > >> maybe we should try to avoid this. > > >> > > > > > > Take a look at dt_pid_has_jump_table() to see how it''s done: > > > > > > > > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/i386/dt_isadep.c#78 > > > > > > Jon. > > > > > > > > >> Thanks > > >> Zhihui > > >> > > >> > > >> 2009/4/23 Jon Haslam <Jonathan.Haslam at sun.com <mailto: > > >> Jonathan.Haslam at sun.com>> > > >> > > >> > > >> Hi Zhihi, > > >> > > >> This could be owing to the fact that there we''ve found jump > > >> tables in the instructions. If DTrace finds jump tables when > > >> attempting to create probes it goes into an ultra conservative > > >> mode of operation. > > >> > > >> To see if this is the problem, set the DTRACE_DEBUG environment > > >> variable before invoking dtrace(1M). Here''s what I see on an > snv_114 > > >> based system when I try to do what you''re doing: > > >> > > >> > > >> # pflags 28997 | grep model > > >> data model = _LP64 flags = MSACCT|MSFORK > > >> # DTRACE_DEBUG=1 dtrace -n pid28997:libc:memcpy:return > > >> <chop> > > >> libdtrace DEBUG: libc.so.1 stret 0 0 0 0 > > >> libdtrace DEBUG: creating probe pid28997:libc.so.1:memcpy:return > > >> libdtrace DEBUG: found a suspected jump table at memcpy:2e > > >> dtrace: invalid probe specifier pid28997:libc:memcpy:return: probe > > >> description pid28997:libc.so.1:memcpy:return does not match any > probes > > >> libdtrace DEBUG: abandoning pid 28997 > > >> > > >> There''s not a whole lot you can do about it. > > >> > > >> Jon. > > >> > > >> I have found that pid provider can not create > > >> memcpy:return probe for 64bit process on snv_110. For example, > > >> the pid is 10603, I will have following output for dtrace > command: > > >> #dtrace -n pid10603:libc.so.1:memcpy:return > > >> dtrace: invalid probe specifier > > >> pid10603:libc.so.1:memcpy:return: probe description > > >> pid10603:libc.so.1:memcpy:return does not match any probes > > >> This just happens for 64bit process, 32bit process > > >> has no such a issue. Following is dtrace output for > 32bit-process > > >> # dtrace -n pid403:libc.so.1:memcpy:return > > >> dtrace: description ''pid403:libc.so.1:memcpy:return'' > > >> matched 1 probe > > >> ^C > > >> Disable shows that 64bit memcpy function has many branches > > >> for ret instructions: # mdb -p 10603 > > >> Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ] > > >> > memcpy::dis ! grep ret > > >> libc.so.1`memcpy+0x5a0: ret > > >> libc.so.1`memcpy+0x631: ret > > >> libc.so.1`memcpy+0x6c2: ret > > >> libc.so.1`memcpy+0x75b: ret > > >> libc.so.1`memcpy+0x7e0: ret > > >> libc.so.1`memcpy+0x879: ret > > >> libc.so.1`memcpy+0x90a: ret > > >> libc.so.1`memcpy+0x9a3: ret > > >> libc.so.1`memcpy+0x1a6c: ret > > >> I dont know whether there is any limitation for dtrace to > > >> create user-level return probe. Does anyone can help explain > > >> this and provide a solution? > > >> Thanks > > >> Zhihi > > >> > > >> > ------------------------------------------------------------------------ > > >> > > >> > > >> > > >> _______________________________________________ > > >> dtrace-discuss mailing list > > >> dtrace-discuss at opensolaris.org > > >> <mailto:dtrace-discuss at opensolaris.org> > > >> > > >> > > >> > > >> > > > > > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss at opensolaris.org > > > -- > Adam Leventhal, Fishworks http://blogs.sun.com/ahl >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20090424/ef9f8af8/attachment.html>
Maybe Matching Threads
- Hwo to disable the polling function of mac_srs
- mac_srs_rx_poll_ring thread never stop polling hardware in kernel
- return from memset on mac osx
- Why is plockstat provider only present for 1 process
- [GE users] Apple Leopard has dtrace -- anyone used the SGE probes/scripts yet?