[dtrace-discuss] USDT providers in shared objects

Adam Leventhal
Thu, 28 Feb 2008 22:17:38 -0000

Hi Mike,

I did a little experiment to try to replicate what you''re describing. I
made
libfoo.so which had a foo provider with a probe foo and libbar.so with a bar
provider and a bar probe. This all seems to work:

# dtrace -l | grep `pgrep main`
58121  bar140134         libbar.so                               bar bar
58122  foo140134         libfoo.so                               foo foo
# dtrace -n foo -n bar
dtrace: description ''foo'' matched 1 probe
dtrace: description ''bar'' matched 1 probe
CPU     ID                    FUNCTION:NAME
  1  58121                          bar:bar
  1  58122                          foo:foo
...

Is there any way you could provide binaries which exhibit this problem?

Further, I confirmed that it''s possible to have a provider of the same
name
in two different shared objects which I think is a better solution to your
problem. The only subtlety is that you have to generate a different .o file
from the provider definition .d file for each shared object:

$ dtrace -h -s provider.d
$ cc -c bar.c foo.c
bar.c:
foo.c:
$ dtrace -G -o bar_provider.o -s provider.d
bar.o
$ dtrace -G -o foo_provider.o -s provider.d
foo.o
$ cc -G -o libbar.so bar.o bar_provider.o
$ cc -G -o libfoo.so foo.o foo_provider.o

Please let me know if you have problems with that.

Adam

On Thu, Feb 28, 2008 at 04:27:54AM -0800, Mike Bell
wrote:
> 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
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl