dtrace discuss - Sep 2007 - dtrace with libtool built library

Hi!

I am trying to work dtrace into a library created with automake and  
libtool. I''ve been playing with this all afternoon but I''ve
hit a
wall on making the following work:

noinst_HEADERS = ha_skeleton.h \
                  skeleton_probes.h

lib_LTLIBRARIES = libskeleton_engine.la
libskeleton_engine_la_SOURCES = ha_skeleton.cc skeleton_probes.d

I''ve added the following suffix rule and header builder:

skeleton_probes.h: skeleton_probes.d
         $(DTRACE) $(DTRACEFLAGS) -h -s skeleton_probes.d
         mv skeleton_probes.h skeleton_probes.h.bak
         sed "s/#include <unistd.h>//g" skeleton_probes.h.bak
>
skeleton_probes.h
         rm skeleton_probes.h.bak

SUFFIXES : .d

.d.o : $(DTRACEFILES)
         $(DTRACE) $(DTRACEFLAGS) -G -s $< $(DTRACEFILES)

The "sed" has to be done to keep the port working on windows (which  
lacks the unistd.h that is generated by the dtrace -h). It would be  
nice to see dtrace fixed so that portability was a bit easier.

The problem? The Dtrace file isn''t built. The fault is more in mine  
in not being able to get automake to do what it should be able to do,  
but when looking around the net I''ve not found where anyone else has  
gotten dtrace to work with libtool libraries either.

Thanks!

Cheers,
    -Brian

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
_______________________________________________________
You can''t grep a dead tree.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070916/51f5c6e9/attachment.html>

Hi Brian,

Brian Aker wrote:
> I am trying to work dtrace into a library created with automake and 
> libtool.
I am intrigued that are trying to do this. What benefits
do you believe a automangled and libtoolised libdtrace
would provide?

> I''ve been playing with this all afternoon but I''ve hit a
wall
> on making the following work:
> 
> noinst_HEADERS = ha_skeleton.h \
> ?? ? ? ? ? ? ? ? skeleton_probes.h
> 
> lib_LTLIBRARIES = libskeleton_engine.la
> libskeleton_engine_la_SOURCES = ha_skeleton.cc skeleton_probes.d
> 
> I''ve added the following suffix rule and header builder:
> 
> skeleton_probes.h: skeleton_probes.d
> ?? ? ? ?$(DTRACE) $(DTRACEFLAGS) -h -s skeleton_probes.d
> ?? ? ? ?mv skeleton_probes.h skeleton_probes.h.bak
> ?? ? ? ?sed "s/#include <unistd.h>//g"
skeleton_probes.h.bak >
> skeleton_probes.h
> ?? ? ? ?rm skeleton_probes.h.bak
> 
> SUFFIXES : .d
> 
> .d.o : $(DTRACEFILES)
> ?? ? ? ?$(DTRACE) $(DTRACEFLAGS) -G -s $< $(DTRACEFILES)
> 
> The "sed" has to be done to keep the port working on windows
(which
> lacks the unistd.h that is generated by the dtrace -h). It would be nice 
> to see dtrace fixed so that portability was a bit easier.
Ok, another question - since there is no port of DTrace for
MS-Windows (at least, not that we know of) - why are you
worrying about this now?

What sort of fixing of DTrace do you have in mind to make
it more portable? Are you aware of how deeply into the kernel
DTrace has its hooks?

> The problem? The Dtrace file isn''t built. The fault is more in
mine in
> not being able to get automake to do what it should be able to do, but 
> when looking around the net I''ve not found where anyone else has
gotten
> dtrace to work with libtool libraries either.
Probably due to a complete lack of desire to do so.
I don''t think there''s anybody who really, seriously,
thinks that doing what you propose is worth the effort.



James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems

Hi!

On Sep 16, 2007, at 8:41 PM, James C. McPherson wrote:
> I am intrigued that are trying to do this. What benefits
> do you believe a automangled and libtoolised libdtrace
> would provide?
The standard skeleton we use for MySQL to build pluggable storage  
engines uses libtool. The code fragment you saw was a breakdown of  
the problem.
> Ok, another question - since there is no port of DTrace for
> MS-Windows (at least, not that we know of) - why are you
> worrying about this now?
The code normally compiles on Windows without any issue normally. The  
include for unistd makes this an issue (though it is easy to get  
around with a simple sed re-edit to the file). Its not about having  
DTrace one Windows, its about using the null defines from the include  
file. This would be easy enough if dtrace -h didn''t add the unistd  
definition.
> Probably due to a complete lack of desire to do so.
> I don''t think there''s anybody who really, seriously,
> thinks that doing what you propose is worth the effort.
Thanks, but without figuring out a straightforward way of including  
this it will make it questionable to use DTrace with MySQL storage  
engines. I would think that there would be a way to make this work.  
I''ve got the patch written for the core, but without figuring out the  
above we won''t be able to make much use of it.

Cheers,
	-Brian

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
_______________________________________________________
You can''t grep a dead tree.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070916/0a72a5cc/attachment.html>

Brian Aker wrote:
> On Sep 16, 2007, at 8:41 PM, James C. McPherson wrote:
>> I am intrigued that are trying to do this. What benefits
>> do you believe a automangled and libtoolised libdtrace
>> would provide?
> The standard skeleton we use for MySQL to build pluggable storage 
> engines uses libtool. The code fragment you saw was a breakdown of the 
> problem.
>> Ok, another question - since there is no port of DTrace for
>> MS-Windows (at least, not that we know of) - why are you
>> worrying about this now?
> 
> The code normally compiles on Windows without any issue normally. The 
> include for unistd makes this an issue (though it is easy to get around 
> with a simple sed re-edit to the file). Its not about having DTrace one 
> Windows, its about using the null defines from the include file. This 
> would be easy enough if dtrace -h didn''t add the unistd
definition.
> 
>> Probably due to a complete lack of desire to do so.
>> I don''t think there''s anybody who really, seriously,
>> thinks that doing what you propose is worth the effort.
> 
> Thanks, but without figuring out a straightforward way of including this 
> it will make it questionable to use DTrace with MySQL storage engines. I 
> would think that there would be a way to make this work. I''ve got
the
> patch written for the core, but without figuring out the above we
won''t
> be able to make much use of it.
Thanks for explaining what you''re getting at - I
have to admit that I was quite concerned by your
original email.

Are you approaching this with the use of SDT probes,
and which DTrace file are you referring to when you
write "The Dtrace file isn''t built" ?


What sort of probes are you defining in skeleton_probes?
Have you tried to #ifdef around the Solaris-specific
definitions and inclusions?



James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems

Hi!

On Sep 16, 2007, at 10:29 PM, James C. McPherson wrote:
> Are you approaching this with the use of SDT probes,
> and which DTrace file are you referring to when you
> write "The Dtrace file isn''t built" ?
Yes. I''ve got a set of SDT probes done for the core of mysqld done.  
What I am now looking at is how we can handle the vendors storage  
engines. The engines can be either dynamically or statically compiled  
into the server. From what I gather we are going to have to change  
our builds for Solaris to make all engines dynamically compiled in  
order to make them visible (aka probes in a library such as  
ha_innodb.a are not going to work).

The skeleton is an example we give to vendors, and we are nearing our  
5.1 release (so I am trying to get this done quickly enough so that  
some of the vendors will have an example of what to do).
> What sort of probes are you defining in skeleton_probes?
> Have you tried to #ifdef around the Solaris-specific
> definitions and inclusions?
Yes. I can do that with:

if BUILD_DTRACE
   libskeleton_engine_la_SOURCES += skeleton_probes.d
endif

We still need to include the output from dtrace -h -s  
skeleton_probes.d, but fixing the Windows compatibility issue was  
simple enough.

The big problem is, the engines/assorted libraries are built with  
libtool. I''m not having much luck sorting out how to make dtrace work  
with this setup. We have dtrace working for the core, but it would be  
nice to instrument the engines as well.

Cheers,
	-Brian

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/                     <-- Me
http://tangent.org/                <-- Software
http://exploitseattle.com/    <-- Fun
_______________________________________________________
You can''t grep a dead tree.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070917/93df2fb1/attachment.html>

Hi Brian,

I am in the group working with the Open MPI community and we use libtool also. 
I am not at the point of generating the .h files from dtrace yet but the code
snippet that follows get me by.  I am definitely interested in what you might
find and if we make further progress ourselfs I''ll post it.

-----Makefile.am-----
....
EXTRA_mca_pml_ob1_la_SOURCES = mpi_provider.d
mca_pml_ob1_la_LIBADD += mpi_provider.o

mpi_provider.o: $(srcdir)/mpi_provider pml_ob1_iprobe.c
             dtrace -G -32 -s $(srcdir)/mpi_provider.d pml_ob1_iprobe.c

--------------------------

--td


--
This message posted from opensolaris.org