dtrace discuss - Sep 2006 - USDT problems in C++ (does putting the probe in a static lib work?)

I''m making my first attempt to add a probe to my application, so I
created a definition file:

    provider fwtools
    {
        probe concurrentq__fixlist();
    };

as my code is C++, I build a header from this thusly:

    # /usr/sbin/dtrace -h -s fwtools.d -o fwtools_probes.h

and in my C++ source file (fwconcurrentqueue.cxx) I have:

    #include "fwtools_probes.h"
    ...
    FWTOOLS_CONCURRENTQ_FIXLIST();

I then create the object file for the probe implementation:

    # /usr/sbin/dtrace -G -s fwtools.d fwconcurrentqueue.o -o
fwtools_probes_nd.o

and this object is included in a static library (libfwtools.a) which is then
linked into a test binary (which uses the class which includes the probe
invocation).

Unfortunately, dtrace tells me that my probe does not exist in my binary:

    # dtrace -P fwtools''$target'' -l -c bin/testq
       ID   PROVIDER            MODULE                          FUNCTION NAME
    dtrace: failed to match fwtools27461:::: No probe matches description

Any ideas what I could be doing wrong here (fwiw, I also tried ''#
dtrace -l -c bin/testq | grep tools'' but got nothing back).

Thanks,

Matt.
 
 
This message posted from opensolaris.org

Matt Stupple stated:
< I''m making my first attempt to add a probe to my application, so I
created a definition file:
< 
<     provider fwtools
<     {
<         probe concurrentq__fixlist();
<     };
< 
< as my code is C++, I build a header from this thusly:
< 
<     # /usr/sbin/dtrace -h -s fwtools.d -o fwtools_probes.h
< 
< and in my C++ source file (fwconcurrentqueue.cxx) I have:
< 
<     #include "fwtools_probes.h"
<     ...
<     FWTOOLS_CONCURRENTQ_FIXLIST();
< 
< I then create the object file for the probe implementation:
< 
<     # /usr/sbin/dtrace -G -s fwtools.d fwconcurrentqueue.o -o
fwtools_probes_nd.o
< 
< and this object is included in a static library (libfwtools.a) which is
then linked into a test binary (which uses the class which includes the probe
invocation).
< 
< Unfortunately, dtrace tells me that my probe does not exist in my binary:
< 
<     # dtrace -P fwtools''$target'' -l -c bin/testq
<        ID   PROVIDER            MODULE                          FUNCTION
NAME
<     dtrace: failed to match fwtools27461:::: No probe matches description
< 
< Any ideas what I could be doing wrong here (fwiw, I also tried ''#
dtrace -l -c bin/testq | grep tools'' but got nothing back).

   Propably related to the question answered last Thursday:
http://www.opensolaris.org/jive/thread.jspa?threadID=12862&tstart=0

    Fixed in build 32.  What version of Solaris are you running ?

Sean.
.

< 
< Thanks,
< 
< Matt.
<  
<  
< This message posted from opensolaris.org
< _______________________________________________
< dtrace-discuss mailing list
< dtrace-discuss at opensolaris.org

> and this object is included in a static library
> (libfwtools.a) which is then linked into a test
> binary (which uses the class which includes the probe
> invocation).
> 
I guess that you must specify the object file created by dtrace on the link-step
in order to get the symbols included in your resulting binary. I _think_ that
the dtrace command replaced the call to the probe with a bunch of no-ops, and
record the location of your probe (offset in symbol table) into the object file
created. Since there is no references from your object file to the generated
object file, it will not be extracted from the archive during linking and
that''s why your application don''t contain any probes.

Please enlighten me if I''m wrong...

Trond
 
 
This message posted from opensolaris.org

This sounds possible ... but the implication of this is that I can''t
*really* define probes for a static library and then have them available in any
executables using the library - instead I have to specifically ''link
in'' the dtrace generated object(s) into every binary which uses the
library.

I''ll try this approach as an interim fix though, and report back how I
get on...

Thanks.
 
 
This message posted from opensolaris.org

> Propably related to the question answered last
>  Thursday:
http://www.opensolaris.org/jive/thread.jspa?threadID=12862&tstart=0
> 
> Fixed in build 32.  What version of Solaris are
> you running ?
snv_40 - so I''m assuming that this is a *different* problem than the
one fixed in build 32.
 
 
This message posted from opensolaris.org

Yes, that does fix it (adding the dtrace generated object to the link line for
the application itself). For reference, I''ve attached a simple test
which demonstrates the problem and the workaround - if you unpack the tarball
and build (note the difference between the link lines for
''bar'' and ''bar2''):

# make
/opt/SUNWspro/bin/CC -c bar.cxx -o bar.o
/usr/sbin/dtrace -h -s foo.d -o foo_probes.h
/opt/SUNWspro/bin/CC -c foo.cxx -o foo.o
/usr/sbin/dtrace -G -s foo.d foo.o -o foo_probes.o
/usr/ccs/bin/ar rv libfoo.a foo.o foo_probes.o
a - foo.o
a - foo_probes.o
ar: creating libfoo.a
ar: writing libfoo.a
/opt/SUNWspro/bin/CC bar.o libfoo.a -o bar
/opt/SUNWspro/bin/CC bar.o libfoo.a foo_probes.o -o bar2

then you should get this from dtrace:

# dtrace -P foo''$target'' -l -c ./bar
   ID   PROVIDER            MODULE                          FUNCTION NAME
dtrace: failed to match foo28588:::: No probe matches description

# dtrace -P foo''$target'' -l -c ./bar2
   ID   PROVIDER            MODULE                          FUNCTION NAME
51288   foo28590              bar2                     __1cDfoo6F_v_ foo

As I mentioned, this isn''t really an acceptable solution at the moment
- my ''real'' application is built from multiple static
libraries each of which may one day include dtrace probes and I don''t
want to have to list each of the generated object files when linking my final
binary ... I suspect that there may be some other ''trick'' I
can use to force the linker to include the dtrace generated object in the output
binary (forcing a symbol reference somehow?) Any ideas?
 
 
This message posted from opensolaris.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtrace_test.tar.gz
Type: application/x-gzip
Size: 564 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060904/ac39b3e0/attachment.bin>

Matt Stupple wrote:
> Yes, that does fix it (adding the dtrace generated object to the link line
for the application itself). For reference, I''ve attached a simple test
which demonstrates the problem and the workaround - if you unpack the tarball
and build (note the difference between the link lines for
''bar'' and ''bar2''):
> 
> # make
> /opt/SUNWspro/bin/CC -c bar.cxx -o bar.o
> /usr/sbin/dtrace -h -s foo.d -o foo_probes.h
> /opt/SUNWspro/bin/CC -c foo.cxx -o foo.o
> /usr/sbin/dtrace -G -s foo.d foo.o -o foo_probes.o
> /usr/ccs/bin/ar rv libfoo.a foo.o foo_probes.o
> a - foo.o
> a - foo_probes.o
> ar: creating libfoo.a
> ar: writing libfoo.a
> /opt/SUNWspro/bin/CC bar.o libfoo.a -o bar
> /opt/SUNWspro/bin/CC bar.o libfoo.a foo_probes.o -o bar2
> 
> then you should get this from dtrace:
> 
> # dtrace -P foo''$target'' -l -c ./bar
>    ID   PROVIDER            MODULE                          FUNCTION NAME
> dtrace: failed to match foo28588:::: No probe matches description
> 
> # dtrace -P foo''$target'' -l -c ./bar2
>    ID   PROVIDER            MODULE                          FUNCTION NAME
> 51288   foo28590              bar2                     __1cDfoo6F_v_ foo
> 
> As I mentioned, this isn''t really an acceptable solution at the
moment - my ''real'' application is built from multiple static
libraries each of which may one day include dtrace probes and I don''t
want to have to list each of the generated object files when linking my final
binary ... I suspect that there may be some other ''trick'' I
can use to force the linker to include the dtrace generated object in the output
binary (forcing a symbol reference somehow?) Any ideas?
>  
There is an appropriate trick.  I can''t currently find a URL to the 
response I got when I asked this same question, but the answer was 
pretty much this:

The linker will not link an entirely unused object that''s in a static 
library.  From the point of view of the linker, the object containing 
the implementation of the dtrace probes (the dtrace-generated object) 
is unused, and thus not linked.

Creating a glommed object of both the dtrace generated object, and your 
other object(s) will get around this:

ld -r -o libthingyglom.o yourobject.o yourotherobject.o \
     dtracegeneratedobject.o

This glommed object can then be used to create the static library.

It isn''t necessary to glom the dtrace generated object together with 
*all* the other objects that would be in the static lib, just enough 
(probably one) for the linker to realize the object is referenced.

Which leads me to another question.  Is there any way the probe 
invocations could be crafted to include a false reference to the 
generated object, such that ld realized it was needed?

-- Rich

On Mon, Sep 04, 2006 at 06:31:31AM -0700, Trond Norbye
wrote:
> I guess that you must specify the object file created by dtrace on
> the link-step in order to get the symbols included in your resulting
> binary. I _think_ that the dtrace command replaced the call to the
> probe with a bunch of no-ops, and record the location of your probe
> (offset in symbol table) into the object file created. Since there is
> no references from your object file to the generated object file, it
> will not be extracted from the archive during linking and that''s
why
> your application don''t contain any probes.
This seems unlikely since the generated object file contains a global
symbol (__SUNW_dof). It would be interesting to know if that symbol was
present in the resulting static library (.a).

Also, is there a reason this is a static library rather than a shared
library?

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

On Mon, Sep 04, 2006 at 02:09:07PM -0700, Adam Leventhal
wrote:
> This seems unlikely since the generated object file contains a global
> symbol (__SUNW_dof). It would be interesting to know if that symbol was
> present in the resulting static library (.a).
It turns out I misremembered the implementation: __SUNW_dof is actually
a locally scoped symbol, but the object file has an init section. I''m
surprised that the presence of an init section doesn''t trigger the
inclusion mechanism from the static library (especially since it might be
needed for other functionality in the archive), but it obviously
doesn''t.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

On Mon, Sep 04, 2006 at 10:58:37AM -0400, Richard Lowe
wrote:
> Which leads me to another question.  Is there any way the probe 
> invocations could be crafted to include a false reference to the 
> generated object, such that ld realized it was needed?
That''s a good idea -- even without static libraries, it would be good
to
have a mechanism that prevented users from omitting the DTrace-generated
object if other objects include DTrace probes.

I''ve filed this RFE on your behalf:

6467121 objects containing USDT probes could require the generated object file

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

> 
> Also, is there a reason this is a static library
> rather than a shared
> library?
> 
Good question. I''m currently of the opinion that for our internal
development framework and the apps built on it, I''d rather have the
''control'' and ''simplicity'' of static linking
(for our libs, obviously not for system libs) so that I know exactly which
version of each component is linked into a production binary when we run into
problems. Of course, we could set up mechanisms for stronger versioning and
identification of shared libs, but we simply don''t have the bandwidth
at the moment...

Matt.
 
 
This message posted from opensolaris.org

Run these commands on the dtrace object file to remove the 
vistigal index stabs before using with "ld -r":

        mcs -d -n .stab.index foo_probes.o
        mcs -d -n .stab.indexstr foo_probes.o

your other problem is:
Arranging for one of the object files from your archive library to be 
always loaded by the linker editor.  You don''t want the end user to
add any special options to their link line.  You want your library to
"just work".

You might be able to swing that by added a dependency
to each object file in your library, so that the linker will suck 
in the dtrace object file as a dependency.

Here is an idea off the top of my head:

1. add a global symbol to the dtrace object file.  Do this by
by creating a dummy object file with the global symbol in
it, then linking that dummy object file using "ld -r" with the
dtrace object file.

2. add a dependency on this global symbol from each
other object file in your library. 

The result would hopefully be:
1. application loads only the parts of your library that
are needed (so it still acts like an archive library)
2. if any of the object files are loaded, then the dtrace
object file is also loaded.

example global symbol:

void __foobar_symbol_dummy() { }

example reference:

(include in a header:)

void __foobar_symbol_dummy();
static void * __dummy = (void*) & __foobar_symbol_dummy;

text symbol and data symbols work slightly differently in the
linker, so you might need to try one or the other kind of 
symbol to get this to work.
 
 
This message posted from opensolaris.org