After some back and forth off the list, Mike and I determined that this was a bug, but one that was fixed in 2005:
6276101 dtrace -G behaves strangely with multiple scripts The latest patch for DTrace should include this fix. Adam On Fri, Feb 29, 2008 at 07:30:34AM -0800, Mike Bell wrote: > Hi Adam, > > Thanks for looking at this - I have repeated your experiment and confirm that > it works fine here too (including having the same provider shared across two > shared libs). So the problem I am seeing must be something to do with what > happens when our application loads libraries. > > To test different scenarios, I have craeted C source files main, foo and bar. > foo and bar are compiled to shared objects and main is compiled to an > excutable. > > If foo and bar have dtrace probes in them, but main does not, you get the > following behaviour: > foo and bar linked to main by specifying -l on the cc command line: all is > well > foo and bar dynamically loaded using dlopen from main: all is well > foo and bar dynamically loaded using dlopen with the RTLD_GLOBAL flag: broken > behaviour - probe foo used for both foo and bar. > > It gets worse if main also uses dtrace. In this case you get broken > behaviour regardless of how foo and bar are linked - you see main's probe > used for all of main, foo and bar. > > >From what I've seen, it looks like dtrace uses the global data __SUNW_dof to > >determine where to insert the probes. I think the problem arises when the > >dtrace init function picks the incorrect __SUNW_dof from the symbol table. > > Does that sound plausible? > > Mike > > > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > [email protected] -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list [email protected]
