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]
