[dtrace-discuss] Newbie Question

[Adam Leventhal]

Hey Daniel,

You can't use dtrace -G on archives. You'll have to pull the archives apart
or build them as shared libraries (with their own USDT providers).

Is there a specific reason why you're using archives?

Adam

On Mon, Jul 23, 2007 at 03:01:32PM -0700, Daniel Templeton wrote:
> Adam,
> 
> Yep.  That's exactly what I'm looking for.  I've read through the links 
> you sent, but I'm still not 100% clear on linking DTrace into the object 
> file, mostly because the project on which I'm working is a little complex.
> 
> Our build process is essentially:
> 
> cc src1a.c
> cc src1b.c
> ...
> ar libsrc1.a src1a.o src1b.o ...
> cc src2a.c
> cc src2b.c
> ...
> ar libsrc2.a src2a.o src2b.o ...
> ...
> cc src98a.c
> cc src98b.c
> ...
> cc -o bin1 libsrc1 libsrc2 ... src98a.o src98b.o ...
> cc src99a.c
> cc src99b.c
> ...
> cc -o bin2 libsrc1 libsrc2 ... src99a.o src99b.o ...
> ...
> 
> Can I use dtrace -G on archives?  I would assume not.  It appears to 
> need to be run against all the object files that compose the binary.  Is 
> that true?  How would I correctly modify this build process to make it 
> work with USDT probes?  I have only one probe provider and header file, 
> but pretty much every file in the system uses the USDT macros defined there.
> 
> Thanks,
> Daniel
> 
> Adam Leventhal wrote:
> > Hi Daniel,
> >
> > It sounds like what you want is is-enabled USDT probes:
> >     http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better
> >
> > Specifically, I suggest you do something like this:
> >
> > ---8<--- dprintf.d ---8<---
> > provider debug {
> > 	probe debug(char *);
> > };
> > --->8--- dprintf.d --->8---
> >
> > ---8<--- dprintf.h ---8<---
> > #define dprintf(...) \
> > 	{ if (DEBUG_DEBUG_ENABLED()) _dprintf(__VA_ARGS__); }
> > --->8--- dprintf.h --->8---
> >
> > ---8<--- dprintf.c ---8<---
> > void
> > _dprintf(const char *fmt, ...)
> > {
> > 	va_list ap;
> > 	char buf[512], *bufp = buf;
> > 	int n;
> >
> > 	va_start(ap, fmt);
> > 	n = vsnprintf(buf, sizeof (buf), fmt, ap);
> > 	va_end(ap);
> >
> > 	if (n >= sizeof (buf)) {
> > 		bufp = alloca(n + 1);
> > 		va_start(ap, fmt);
> > 		n = vsprintf(bufp, fmt, ap);
> > 		va_end(ap);
> > 	}
> >
> > 	DEBUG_DEBUG(bufp);
> > }
> > --->8--- dprintf.c --->8---
> >
> > Then from your code you can call dprintf() and incur basically no overhead.
> > You can use a very simple D script to format the output:
> >
> > ---8<---
> >
> > #!/usr/sbin/dtrace -s
> >
> > #pragma D option quiet
> >
> > debug*:::debug
> > {
> > 	printf("%s\n", copyinstr(arg0));
> > }
> >
> > --->8---
> >
> > I'd actually like to see something like this ship as a Solaris library...
> >
> > Adam
> >
> > On Mon, Jul 23, 2007 at 12:37:57PM -0700, Daniel Templeton wrote:
> >   
> >> Hi,
> >>
> >> I'm working on a project where I would like to use DTrace to plug into 
> >> printf* calls being made by a deamon and print out what those printfs 
> >> would be printing were the daemon's output stream not getting dumped 
> >> into the bit bucket.  I can connect to the daemon and grab the printf 
> >> calls and print the format string, but how do I deal with the printf 
> >> varargs?  Not only do I not know how many args there are, I don't know 
> >> which ones are numbers (and can be used directly), and which ones are 
> >> pointers/strings (and must be copyin'ed or copyinstr'ed).  I don't see 
> >> any way in D to process the format string to find the answers.  Any 
> >> clever tricks for handling something like this?
> >>
> >> * The printf calls aren't actually printf() calls.  They are calls to an 
> >> internal routine that functions similarly to printf(), with a caveat.  
> >> Unless debugging is turned on (by setting an env var), the contents of 
> >> the printf's won't be executed.  It does a cheap test and returns if no 
> >> debug output is requested.  My real objective is to use DTrace to be 
> >> able to dynamically turn on debugging by plugging into the printf calls 
> >> themselves, so that restarting the daemon to get debug output is no 
> >> longer required.  This is an old and large source base, so I'm trying to 
> >> avoid massive code overhauls to reach my goal.
> >>
> >> Thanks,
> >> Daniel
> >> _______________________________________________
> >> dtrace-discuss mailing list
> >> dtrace-discuss at opensolaris.org
> >>     
> >
> >   
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl