Joe Pallas
pallas@cs.stanford.edu
|
|
|
|
[dtrace-discuss] More fun with USDT and static libraries on Solaris
Posted:
Nov 2, 2009 12:17 PM
|
|
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 dot org
|
|
|
Adam Leventhal
ahl@eng.sun.com
|
|
|
|
Re: [dtrace-discuss] More fun with USDT and static libraries on
Solaris
Posted:
Nov 4, 2009 5:30 PM
in response to: Joe Pallas
|
|
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 dot org
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
Posts:
5,507
From:
US
Registered:
3/9/05
|
|
|
|
Re: [dtrace-discuss] More fun with USDT and static libraries on
Solaris
Posted:
Nov 4, 2009 7:03 PM
in response to: Joe Pallas
|
|
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 dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris dot org
|
|
|
|
|
