2008/8/15 <[EMAIL PROTECTED]>: > >> ------------ Původní zpráva ------------ >> Od: Chad Mynhier <[EMAIL PROTECTED]> >> Předmět: Re: [dtrace-discuss] pid: excluding libraries, modules >> Datum: 15.8.2008 14:04:25 >> ---------------------------------------- >> On Fri, Aug 15, 2008 at 3:21 AM, <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > I am facing another problem with pid provider. I'd like to trace my >> application but would like to not to trace libc and libnsl. I could use >> predicate like /probemod != "libc" && probemod != "libnsl"/ but having this >> dtrace keeps inserting probes into those libraries which causes considerable >> hardware resources consumption. So I would probably need to exclude it in >> probe >> description but patterns in probe descption doesn't seem to allow me to do >> what >> I need. >> > >> > Does someone know any workaround or are there any plans for some >> > improvement >> in this area? I know I am now the only one who is experiencing this problem: >> http://mail.opensolaris.org/pipermail/dtrace-discuss/2005-November/000729.html >> >> Given you can't exclude these two libraries, another option is to >> explicitly list the other libraries that you're interested in, or >> simply your application if that's all that you care about. >> > > Yes, that would be an option but I would rather avoid difficult searching thru > application's library dependencies and specifying lot of libraries explicitly > - > for complex application this could be a really big amount.
Hmm, so looking further at this, it seems that you should be able to do this. The code is using gmatch(3GEN) to match these patterns, so you should be able to use some convoluted shell globbing construct to do what you want. For example, this should exclude libc (although it would also exclude libcfoo, so it's not a complete example): pid$target:lib[!c]*::entry Some debugging of the code, though, seems to show that we're not matching what we should be. The function dt_pid_mod_filt() (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/common/dt_pid.c#368) is where the match should be occurring: 373 if (gmatch(obj, pp->dpp_mod)) 374 return (dt_pid_per_mod(pp, pmp, obj)); 375 376 (void) Plmid(pp->dpp_pr, pmp->pr_vaddr, &pp->dpp_lmid); 377 378 if ((pp->dpp_obj = strrchr(obj, '/')) == NULL) 379 pp->dpp_obj = obj; 380 else 381 pp->dpp_obj++; 382 383 dt_pid_objname(name, sizeof (name), pp->dpp_lmid, obj); 384 385 if (gmatch(name, pp->dpp_mod)) 386 return (dt_pid_per_mod(pp, pmp, obj)); Throwing some dt_dprintf() debugging in here shows that it's actually trying to match a full pathname. For these probes: pid$target:[c]hadfoo::entry, pid$target:libn*::entry With dt_dprintf() statements like this just before the two gmatch(3GEN) calls: dt_dprintf("CHADFOO: Trying to match %s to %s\n", obj, pp->dpp_mod); dt_dprintf("CHADFOO: Trying to match %s to %s\n", name, pp->dpp_mod); I get this (pertinent) debugging output: libdtrace DEBUG: CHADFOO: Trying to match /tmp/chadfoo/chadfoo to [c]hadfoo libdtrace DEBUG: CHADFOO: Trying to match /tmp/chadfoo/chadfoo to [c]hadfoo libdtrace DEBUG: CHADFOO: Trying to match /lib/libnsl.so.1 to libn* libdtrace DEBUG: CHADFOO: Trying to match /lib/libnsl.so.1 to libn* I've not dug into the gmatch(3GEN) code yet, but I'd guess that it's not matching because of the fully-qualified pathnames. Is this a bug that just needs a basename(3C) call? (I went looking for a bug that matches this, but I couldn't find anything. I'll open a bug if nobody else knows of an existing one.) Chad _______________________________________________ dtrace-discuss mailing list [email protected]
