On Jan 20, 2010, at 7:31 AM, Jon Haslam wrote: > Hi Joe, > > Thanks for the good test case. > > Yes, this seems to be a bug. It appears that we end up generating > malformed DOF when unreferenced providers are included as in your > example. This will mean that we reject the DOF when it's loaded > into the kernel and you therefore don't get any probes. I've logged: > > 6918387: DOF rejected if unreferenced USDT providers are included > > I'm a bit short of time at the minute to look at this but let > me know if it's causing major problems. > > Thanks. > > Jon.
Well, this is a bit of a nuisance. I'm trying to work around the problem with probes in project static libraries by using the "ld -r" trick suggested by Alan Coopersmith, but at executable link time rather than at library creation time. (See earlier thread "More fun with USDT and static libraries on Solaris") That means I need to process each partially linked executable with all the providers that it uses. My plan had been to have a single provider file for each library, and just put all of those on the dtrace -G line. It looks like I need to do two things to work around this issue: 1) Don't include multiple providers in a single .d file, unless I am certain that either all of them are used or none of them are. That's unlikely, so I'll probably need to have one .d file per provider. 2) Examine the executable before running dtrace -G to determine which providers are actually used, and include only those D files on the command line. I was already needing a script to do linking anyway, so the second part is just more work for it to do, assuming that I can rely on "nm -u | grep __dtrace" to identify the probes that are actually used. It's unfortunate that the two approaches interact to make the task just a bit messier. Do you see any obvious problems with this before I invest some effort in trying it out? Thanks. joe _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
