Hi, We have a large application that uses dozens of shared objects that I'm trying to add dtrace probes into. Ideally, I'd like to have a single provider with a bunch of probes that could be triggered at various points throughout all of the libraries. However, this is impossible because you have to run dtrace -G against all of the objects for a provider at once.
I'm trying to work around this by having a separate provider for each shared object, autogenerated from a template, so each provider has a bunch of probes with the same names. I've got this to work providing only one shared object is linked with dtrace, but as soon as 2 shared objects are linked with dtrace I get weird results - according to dtrace -l the second library to load seems to get it's probes named as for the first library. dtrace -l if only libdcmge.so is compiled with dtrace probes in it: 5892 metadcmge5665 libdcmge.so mw_mge_media_format_lookup trc-flow 5893 metadcmge5665 libdcmge.so mw_mge_mega_build_term_name trc-flow 5894 metadcmge5665 libdcmge.so mw_mge_check_term_numbering trc-flow ... dtrace-l if both libnbase.so and libdcmge.so are compiled with probes in them: 7242 metanbase11957 libnbase.so nbb_dispatch_process ips-dispatch 7243 metanbase11957 libnbase.so yadf_log_connection_failure trc-flow 7244 metanbase11957 libnbase.so yadf_start_keepalives trc-flow ... 49479 metanbase11957 libdcmge.so nbb_dispatch_process ips-dispatch 49480 metanbase11957 libdcmge.so yadf_log_connection_failure trc-flow 49481 metanbase11957 libdcmge.so yadf_start_keepalives trc-flow Is the problem that you can you only have one USDT provider per-executable, or is it re-using the same probe names with different providers that causes the problem, or something else? Cheers, Mike -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list [email protected]
