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
dtrace-discuss@opensolaris.org

Reply via email to