search for: pid123

I have a test program which has a call sequence of a(), b(), c(), d(). When I place a pid return probe on d(), I get a ustack that looks like this: a.out`d+0x19 a.out`b+0xd a.out`a+0xd a.out`main+0x3c a.out`_start+0x7a The c() method appears to be missing. I did some poking around and noticed that pid return probes

Page 43: Gotcha: Unsporting apps Last Bullet: Can still use the pid provider to instrument instructdions in stripped functions by using "-" as the probe function and the address of the instruction as the name: #dtrace -n pid123::-:80704e3 How does one begin to discover the "address"? This message posted from opensolaris.org

Tracing Fans, I know it''s been a long time in coming but the CPU Performance Counter (CPC) provider is almost here! The code is currently in for review and a proposed architecture document is attached here for review. Any and all feedback/questions on the proposed implementation is welcome. Thanks. Jon. -------------- next part -------------- An embedded and charset-unspecified text

...land, dtrace can probe any assembly language instruction. >From the dtrace guide: Function Offset Probes The pid provider lets you trace any instruction in a function. For example to trace the instruction 4 bytes into a function main(), you could use a command similar to the following example: pid123:a.out:main:4 Every time the program executes the instruction at address main+4, this probe will be activated. The arguments for offset probes are undefined. The uregs[] array will help you examine process state at these probe sites. See "uregs[] Array" on page 352 for more information....

I''m trying to do some userspace tracing on a server-process with the pid provider. My problem is, that the only probes the pid-provider lists for the server-process (to which I attach dtrace with "-p nnnn") are coming from "ld.so.1". There''s not a single one from my modules. If I''m specifying "a.out" (or any of our shared-objects) as the