On Tue, Mar 16, 2010 at 08:55:04AM -0700, tester wrote: > It is somewhat complex for someone like me with limited C programming > to unearth the actual data(args and result) from the door call API. I > beleive it has custom NSS headers packed along with actual data. > Tracemem for most part is not that meaningful. If anyone has already > done this, please share it.
Ok, so you're trying to observe name service calls. (There are other doors in use in Solaris besides the one for nscd.) What you need is a way to parse the door call argument data buffer and the door return rbuf too. I don't see where that's documented in the source (the protocol itself is private, but it should be documented in source), so I'm cc'ing two people who can help you with that. (The relevant source code is in $SRC/lib/libc/port/gen/nss_common.c.) > I am startting to look at other places where I can get this data in a > strcutured form. I started looking at > > pid$target:libc:_nsc_try1door:entry That function receives the call data/results already packed. Also, on the client side there are many more processes to trace than on the server side. I recommend tracing the server-side if at all possible. Besides, if you're tracing the server you don't need to worry about 32-bit vs. 64-bit -- the server in this is always 32-bit because nscd is only built in 32-bit. Nico -- _______________________________________________ dtrace-discuss mailing list [email protected]
