Hi,
I''m currently trying to place SDT probes in a C++ program. As I found
out by looking at the sys/sdt.h header that is not really possible, since the
probe linkage-specification reads only "extern", which will by C++
compilers be interpreted as (default) C++ linkage. Since the probes are in fact
generated with extern "C" linkage the linker found find the symbols
when putting it all together. Change that to a simple "extern
"C"" for "__cplusplus"-compilations will of course not
work since extern "C" declarations are only allowed at filescope in
C++ (duh!).
OK, figuring that, I found the following and I''m pretty sure that is at
least one of the issues referred to by Bryan Cantrill when responding to this
"http://elliotth.blogspot.com/2005/07/book-exceptional-c-style.html"
blog entry:
"DTrace is written entirely in C; the libdtrace API is entirely an extern
"C" API, and we don''t support USDT probes in C++. (Due to
regrettable restrictions around the extern "C" construct.) The C++
naming conventions therefore do not apply to us ? and there is no such
restriction around __ in the middle of C identifiers."
OK, now for the actual question(s):
(1) Is there any C++ support planned for DTrace (e.g. having an additional
option to dtrace that will generated C++ mangled probe names or so)
(2) I "worked around" that by basically copying the DTRACE_PROBEx
macros, and adding additional
PROBE_D_x macros which I call at file scope (they simply have the extern
"C" declaration for the
probes prototype''s.
In the end it looks something like this:
// file.cpp
#include "mysdt.h"
PROBE_D_0(demo, foo)
PROBE_D_1(demo, bar)
//...
void my::func()
{
int x = 0;
PROBE0(demo, foo);
PROBE1(demo, bar, x);
}
Obviously not as nice as only having to write the "DTRACE_PROBEx"
statements, but it works for me.
Is this something you could provide as part of sys/sdt.h (in addition to the
current macros)?
Since I needed to copy the "DTRACE_PROBEx" macros, how stable are they
anyway?
(3) Appart from the linkage issue (and maybe all sorts of mangling-trouble) are
there any others gotaches with C++ (USDT-enriched) programs?
Thanks,
Chris
This message posted from opensolaris.org
Hi Chris, Adding USDT probes to C++ is indeed a pain, and we''ve mostly worked around it in the way you''ve described, by splitting the macro into two pieces: one that "declares" the probe as extern "C" at the file level and the other macro that invokes the probe. We''re planning to simplify this in the future not by dealing with mangled C++ names (essentially a non-starter since each C++ compiler uses its own mangling scheme), but rather by adding a new option to dtrace(1M) which will take your USDT provider declaration file and generate a header file which a bunch of macros of the form DTRACE_<PROVIDER>_<PROBE>(). Rather than including <sys/sdt.h>, you''ll include this file. It''s not beautiful, but we think it''s much nicer (we''d welcome any input). We encountered these problems when adding probes to the JVM (which is written in C++). To my knowledge, there were no other gotchas. Adam On Thu, Aug 11, 2005 at 07:22:57AM -0700, Christian Klutz wrote:> Hi, > > I''m currently trying to place SDT probes in a C++ program. As I found out by looking at the sys/sdt.h header that is not really possible, since the probe linkage-specification reads only "extern", which will by C++ compilers be interpreted as (default) C++ linkage. Since the probes are in fact generated with extern "C" linkage the linker found find the symbols when putting it all together. Change that to a simple "extern "C"" for "__cplusplus"-compilations will of course not work since extern "C" declarations are only allowed at filescope in C++ (duh!). > > OK, figuring that, I found the following and I''m pretty sure that is at least one of the issues referred to by Bryan Cantrill when responding to this "http://elliotth.blogspot.com/2005/07/book-exceptional-c-style.html" blog entry: > > "DTrace is written entirely in C; the libdtrace API is entirely an extern "C" API, and we don''t support USDT probes in C++. (Due to regrettable restrictions around the extern "C" construct.) The C++ naming conventions therefore do not apply to us ? and there is no such restriction around __ in the middle of C identifiers." > > OK, now for the actual question(s): > > (1) Is there any C++ support planned for DTrace (e.g. having an additional option to dtrace that will generated C++ mangled probe names or so) > > (2) I "worked around" that by basically copying the DTRACE_PROBEx macros, and adding additional > PROBE_D_x macros which I call at file scope (they simply have the extern "C" declaration for the > probes prototype''s. > > In the end it looks something like this: > // file.cpp > #include "mysdt.h" > > PROBE_D_0(demo, foo) > PROBE_D_1(demo, bar) > > //... > > void my::func() > { > int x = 0; > PROBE0(demo, foo); > PROBE1(demo, bar, x); > } > > Obviously not as nice as only having to write the "DTRACE_PROBEx" statements, but it works for me. > > Is this something you could provide as part of sys/sdt.h (in addition to the current macros)? > Since I needed to copy the "DTRACE_PROBEx" macros, how stable are they anyway? > > (3) Appart from the linkage issue (and maybe all sorts of mangling-trouble) are there any others gotaches with C++ (USDT-enriched) programs? > > Thanks, > Chris > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
On Fri, Aug 12, 2005 at 07:54:04AM +0200, cklutz at gmail.com wrote:> > We''re planning to simplify this in the future not by dealing with mangled > > C++ names (essentially a non-starter since each C++ compiler uses its own > > mangling scheme), but rather by adding a new option to dtrace(1M) which > > will take your USDT provider declaration file and generate a header file > > which a bunch of macros of the form DTRACE_<PROVIDER>_<PROBE>(). > > Is there any particular reason why you are choosing to include the > actual names in the macros, rather than specifying them as parameters > to a generic macro? > (Maybe to test for "#ifdef DTRACE_<PROVIDER>_<PROBE>" somewhere?).So you can''t specify arbitrary probe names -- by only generating macros for the probes in the provider definition file, you can catch incorrect probe names when you compile the c file rather than when you try to post-process the object file.> > Rather than including <sys/sdt.h>, you''ll include this file. It''s not beautiful, > > but we think it''s much nicer (we''d welcome any input). > > Actually that is what I''m doing already ;-) I have hacked together a > little .d provider/probe parser which spits out such header files [1].Sounds cool. I''m sure this would be a useful tool if you wanted to publish it in some way (post it here, blog about it, etc). Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl