dtrace discuss - Nov 2009 - More fun with USDT and static libraries on Solaris

Standard disclaimer: working with an existing code base that uses  
static libraries and would be difficult to convert to shared objects.

So, I tweaked the build process to have all the providers used by a  
given library in one D file, run dtrace -G over all the objects going  
into that library, and add a symbol definition to the generated  
provider.o so that the linker would pull in the provider.o file from  
the archive at link time.

It seems to work, but I discovered that an executable linked with two  
DTrace-enhanced libraries doesn''t work right.  It appears that DTrace  
only sees the providers from the first library in the link.  That is,  
if I link with -lred -lblue, I''ll see only the red providers in dtrace
-l, but if I link with -lblue -lred I''ll see only the blue providers.

elfdump seems to show that I''ve got two SUNW_dof sections in the  
executable. Is that the source of the problem?  If so, should DTrace  
handle multiple SUNW_dof sections?  Should the linker be able to merge  
SUNW_dof sections?  Is this completely irrelevant?

Any advice would be useful here.  At this point I''m willing to  
consider advice of the form, "Solaris DTrace is never going to work  
for multiple static libraries, give up trying," although I''ll be  
disappointed.  MacOS seems to handle this case.

Thanks.
joe

Hey Joe,

We''re aware of some issues with USDT and static libraries. As
you''ve
identified,
the linker is not able to merge them.

For the time being I''d say to give up on static libraries on Solaris.

If the Mac OS X guys would like to contribute their modifications back  
into
Solaris, that would be quite welcome.

Adam

On Nov 2, 2009, at 12:17 PM, Joe Pallas wrote:
> Standard disclaimer: working with an existing code base that uses  
> static libraries and would be difficult to convert to shared objects.
>
> So, I tweaked the build process to have all the providers used by a  
> given library in one D file, run dtrace -G over all the objects  
> going into that library, and add a symbol definition to the  
> generated provider.o so that the linker would pull in the provider.o  
> file from the archive at link time.
>
> It seems to work, but I discovered that an executable linked with  
> two DTrace-enhanced libraries doesn''t work right.  It appears that
> DTrace only sees the providers from the first library in the link.   
> That is, if I link with -lred -lblue, I''ll see only the red  
> providers in dtrace -l, but if I link with -lblue -lred I''ll see  
> only the blue providers.
>
> elfdump seems to show that I''ve got two SUNW_dof sections in the  
> executable. Is that the source of the problem?  If so, should DTrace  
> handle multiple SUNW_dof sections?  Should the linker be able to  
> merge SUNW_dof sections?  Is this completely irrelevant?
>
> Any advice would be useful here.  At this point I''m willing to  
> consider advice of the form, "Solaris DTrace is never going to work  
> for multiple static libraries, give up trying," although I''ll
be
> disappointed.  MacOS seems to handle this case.
>
> Thanks.
> joe
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

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

Joe Pallas wrote:
> Standard disclaimer: working with an existing code base that uses static
> libraries and would be difficult to convert to shared objects.
> 
> So, I tweaked the build process to have all the providers used by a
> given library in one D file, run dtrace -G over all the objects going
> into that library, and add a symbol definition to the generated
> provider.o so that the linker would pull in the provider.o file from the
> archive at link time.
> 
> It seems to work, but I discovered that an executable linked with two
> DTrace-enhanced libraries doesn''t work right.  It appears that
DTrace
> only sees the providers from the first library in the link.  That is, if
> I link with -lred -lblue, I''ll see only the red providers in
dtrace -l,
> but if I link with -lblue -lred I''ll see only the blue providers.
When I added the dtrace probes to the Xorg build process, the best solution
I found was to replace the static libraries with relocatable objects built
with ld -r -- like static libraries the code from them gets copied into the
final executable, but you would have to change the linker code to refer to
those files directly instead of -lfoo.

(BTW, as of last month''s Xorg 1.7 release, the dtrace probes are also
built
 on MacOS as well - though that broke the Solaris dtrace probe build until
 the 1.7.1 release fixed it.)

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering