[dtrace-discuss] USDT providers in shared objects

Adam Leventhal
Mon, 03 Mar 2008 18:06:07 -0000

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
> dtrace-discuss at opensolaris.org

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