dtrace discuss - Aug 2005 - can we split dtrace provider definition into several files?

Hi,

I am trying to add dtrace probes to our application and facing a problem. 
Namely, .d file looks like this (don''t ask):

$ cat ./dsax.d

provider dsax {
         probe ufncall(string);
         probe af_entry(string);
         probe af_return(string);
         probe if_entry(string);
         probe if_return(string);
         probe qdna_entry(string);
         probe qdna_return(string);
};

but all probes, except af_return() are called from functions defined in 
one file, xauxxx.c, whereas af_return() is called from a function defined 
in a different file, xgoto0.c Now, since these are static probes, I have 
to bypass linker''s cleverness (as discussed recently here), so my
Makefile
looks something like this (q&d hack):

xauxxx.o: xauxxx.c dsax.d
         /bin/rm -f dsax.o xa.o
         $(CC) $(CFLAGS) -c -o xa.o $<
         /usr/sbin/dtrace -G -32 -o dsax.o -s dsax.d xa.o
         ld -r -o $@  dsax.o xa.o

xgoto0.o: xgoto0.c dsax.d
         /bin/rm -f dsax1.o xa1.o
         $(CC) $(CFLAGS) -O0 -c -o xa1.o $<
         /usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xa1.o
         ld -r -o $@  dsax1.o xa1.o
         /bin/rm -f dsax1.o xa1.o

However, I am now getting the following error:

ld: fatal: symbol `__SUNW_dof'' is multiply-defined:
         (file /home/dragan/sc1/sax/lib/libsax.a(xauxxx.o) type=OBJT; file 
/home/dragan/sc1/sax/lib/libsax.a(xgoto0.o) type=OBJT);

If I compile e.g. just xauxxx.o combined with dsax.d, then af_return() is 
not visible as it is only used by xgoto0.o. I can''t combine xauxxx.c
and
xgoto0.c into a single file, but can do whatever I want with .d files.

Any advise?

TIA, Dragan

-- 
Dragan Cvetkovic,

To be or not to be is true. G. Boole    No it isn''t.  L. E. J. Brouwer

On Thu, Aug 25, 2005 at 03:19:34PM -0400, Dragan Cvetkovic
wrote:
> 	Hi,
> 
> I am trying to add dtrace probes to our application and facing a problem. 
> Namely, .d file looks like this (don''t ask):
> 
> $ cat ./dsax.d
> 
> provider dsax {
>         probe ufncall(string);
>         probe af_entry(string);
>         probe af_return(string);
>         probe if_entry(string);
>         probe if_return(string);
>         probe qdna_entry(string);
>         probe qdna_return(string);
> };
> 
> but all probes, except af_return() are called from functions defined in 
> one file, xauxxx.c, whereas af_return() is called from a function defined 
> in a different file, xgoto0.c Now, since these are static probes, I have 
> to bypass linker''s cleverness (as discussed recently here), so my
Makefile
> looks something like this (q&d hack):
> 
> xauxxx.o: xauxxx.c dsax.d
>         /bin/rm -f dsax.o xa.o
>         $(CC) $(CFLAGS) -c -o xa.o $<
>         /usr/sbin/dtrace -G -32 -o dsax.o -s dsax.d xa.o
>         ld -r -o $@  dsax.o xa.o
> 
> xgoto0.o: xgoto0.c dsax.d
>         /bin/rm -f dsax1.o xa1.o
>         $(CC) $(CFLAGS) -O0 -c -o xa1.o $<
>         /usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xa1.o
>         ld -r -o $@  dsax1.o xa1.o
>         /bin/rm -f dsax1.o xa1.o
> 
> However, I am now getting the following error:
> 
> ld: fatal: symbol `__SUNW_dof'' is multiply-defined:
>         (file /home/dragan/sc1/sax/lib/libsax.a(xauxxx.o) type=OBJT; file 
> /home/dragan/sc1/sax/lib/libsax.a(xgoto0.o) type=OBJT);
> 
> If I compile e.g. just xauxxx.o combined with dsax.d, then af_return() is 
> not visible as it is only used by xgoto0.o. I can''t combine
xauxxx.c and
> xgoto0.c into a single file, but can do whatever I want with .d files.
Why don''t you compile xauxxx.o and xgoto0.o normally, but then make a
new
object to link in, like:

xdtrace.o: xgoto0.o xauxxx.o
	/usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xgoto0.o xauxx.o
	ld -r -o $@ dsax1.o xgoto0.o xauxx.o

then link in xdtrace.o.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

On Thu, 25 Aug 2005, Jonathan Adams wrote:
> On Thu, Aug 25, 2005 at 03:19:34PM -0400, Dragan Cvetkovic wrote:
>>
>> I am trying to add dtrace probes to our application and facing a
problem.
>> Namely, .d file looks like this (don''t ask):
>>
>> $ cat ./dsax.d
>>
>> provider dsax {
>>         probe ufncall(string);
>>         probe af_entry(string);
>>         probe af_return(string);
>>         probe if_entry(string);
>>         probe if_return(string);
>>         probe qdna_entry(string);
>>         probe qdna_return(string);
>> };
>>
>> but all probes, except af_return() are called from functions defined in
>> one file, xauxxx.c, whereas af_return() is called from a function
defined
>> in a different file, xgoto0.c Now, since these are static probes, I
have
>> to bypass linker''s cleverness (as discussed recently here), so
my Makefile
>> looks something like this (q&d hack):
[snip]
>>
>> However, I am now getting the following error:
>>
>> ld: fatal: symbol `__SUNW_dof'' is multiply-defined:
>>         (file /home/dragan/sc1/sax/lib/libsax.a(xauxxx.o) type=OBJT;
file
>> /home/dragan/sc1/sax/lib/libsax.a(xgoto0.o) type=OBJT);
>>
>> If I compile e.g. just xauxxx.o combined with dsax.d, then af_return()
is
>> not visible as it is only used by xgoto0.o. I can''t combine
xauxxx.c and
>> xgoto0.c into a single file, but can do whatever I want with .d files.
>
> Why don''t you compile xauxxx.o and xgoto0.o normally, but then
make a new
> object to link in, like:
>
> xdtrace.o: xgoto0.o xauxxx.o
> 	/usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xgoto0.o xauxx.o
> 	ld -r -o $@ dsax1.o xgoto0.o xauxx.o
>
> then link in xdtrace.o.
Hi Jonathan, I guess that would work but would mess the building process 
for non-Solaris 10 (and non-Solaris) machines.

Bye, Dragan

-- 
Dragan Cvetkovic,

To be or not to be is true. G. Boole    No it isn''t.  L. E. J. Brouwer

On Thu, Aug 25, 2005 at 04:27:28PM -0400, Dragan Cvetkovic
wrote:
> >>If I compile e.g. just xauxxx.o combined with dsax.d, then
af_return() is
> >>not visible as it is only used by xgoto0.o. I can''t
combine xauxxx.c and
> >>xgoto0.c into a single file, but can do whatever I want with .d
files.
> >
> >Why don''t you compile xauxxx.o and xgoto0.o normally, but then
make a new
> >object to link in, like:
> >
> >xdtrace.o: xgoto0.o xauxxx.o
> >	/usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xgoto0.o xauxx.o
> >	ld -r -o $@ dsax1.o xgoto0.o xauxx.o
> >
> >then link in xdtrace.o.
> 
> Hi Jonathan, I guess that would work but would mess the building process 
> for non-Solaris 10 (and non-Solaris) machines.
Well then, only do the "ld -r" trick on one of the binaries; the other
will
be referenced by the dsax.o stuff.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

On Thu, 25 Aug 2005, Jonathan Adams wrote:
> On Thu, Aug 25, 2005 at 04:27:28PM -0400, Dragan Cvetkovic wrote:
>>>> If I compile e.g. just xauxxx.o combined with dsax.d, then
af_return() is
>>>> not visible as it is only used by xgoto0.o. I can''t
combine xauxxx.c and
>>>> xgoto0.c into a single file, but can do whatever I want with .d
files.
>>>
>>> Why don''t you compile xauxxx.o and xgoto0.o normally, but
then make a new
>>> object to link in, like:
>>>
>>> xdtrace.o: xgoto0.o xauxxx.o
>>> 	/usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xgoto0.o xauxx.o
>>> 	ld -r -o $@ dsax1.o xgoto0.o xauxx.o
>>>
>>> then link in xdtrace.o.
>>
>> Hi Jonathan, I guess that would work but would mess the building
process
>> for non-Solaris 10 (and non-Solaris) machines.
>
> Well then, only do the "ld -r" trick on one of the binaries; the
other will
> be referenced by the dsax.o stuff.
No, it won''t:

Undefined                       first referenced
  symbol                             in file
__dtrace_dsax___af_return           /home/dragan/sc1/sax/lib/libsax.a(xgoto0.o)

That (af_return) is the probe called from the other file.

Dragan

-- 
Dragan Cvetkovic,

To be or not to be is true. G. Boole    No it isn''t.  L. E. J. Brouwer

On Thu, 25 Aug 2005, Jonathan Adams wrote:
> On Thu, Aug 25, 2005 at 04:27:28PM -0400, Dragan Cvetkovic wrote:
>>>> If I compile e.g. just xauxxx.o combined with dsax.d, then
af_return() is
>>>> not visible as it is only used by xgoto0.o. I can''t
combine xauxxx.c and
>>>> xgoto0.c into a single file, but can do whatever I want with .d
files.
>>>
>>> Why don''t you compile xauxxx.o and xgoto0.o normally, but
then make a new
>>> object to link in, like:
>>>
>>> xdtrace.o: xgoto0.o xauxxx.o
>>> 	/usr/sbin/dtrace -G -32 -o dsax1.o -s dsax.d xgoto0.o xauxx.o
>>> 	ld -r -o $@ dsax1.o xgoto0.o xauxx.o
>>>
>>> then link in xdtrace.o.
>>
>> Hi Jonathan, I guess that would work but would mess the building
process
>> for non-Solaris 10 (and non-Solaris) machines.
>
> Well then, only do the "ld -r" trick on one of the binaries; the
other will
> be referenced by the dsax.o stuff.
I am now completely confused: I have 3 files that have dtrace probes in 
them in two different directories and to resolve the problem, I have 
created a new file (in a third directory) with the following context:

/* include approriate headers here */
/* used only to make dtrace probes visable */

void dtrace_probe_dummy(void)
{
   DTRACE_PROBE1(dsax,ufncall,"nosuchfunction");
   DTRACE_PROBE1(dsax,af_entry,"nosuchfunction");
   DTRACE_PROBE1(dsax,af_return,"nosuchfunction");
   DTRACE_PROBE1(dsax,if_entry,"nosuchfunction");
   DTRACE_PROBE1(dsax,if_return,"nosuchfunction");
   DTRACE_PROBE1(dsax,qdna_entry,"nosuchfunction");
   DTRACE_PROBE1(dsax,qdna_return,"nosuchfunction");
}

and the corresponding dsax.d file is as before:

provider dsax {
         probe ufncall(string);
         probe af_entry(string);
         probe af_return(string);
         probe if_entry(string);
         probe if_return(string);
         probe qdna_entry(string);
         probe qdna_return(string);
};

Makefile entry for generating dsax.o is

dsax.o: dsax.c dsax.d
         /bin/rm -f d1.o d2.o
         $(CC) $(CFLAGS) -c -o d1.o $<
         /usr/sbin/dtrace -G -32 -o d2.o -s dsax.d d1.o
         $(LD) -r -o $@  d1.o d2.o
         /bin/rm -f d1.o d2.o


So now I have 4 files in my libsax.a file having anything to do with 
dtrace:

1. xauxxx.o:

nm xauxxx.o | grep _dtrace
[32]    |         0|       0|NOTY |GLOB |0    |UNDEF  |__dtrace_dsax___af_entry
[23]    |         0|       0|NOTY |GLOB |0    |UNDEF  |__dtrace_dsax___if_entry
[26]    |         0|       0|NOTY |GLOB |0    |UNDEF  |__dtrace_dsax___if_return
[28]    |         0|       0|NOTY |GLOB |0    |UNDEF 
|__dtrace_dsax___qdna_entry
[30]    |         0|       0|NOTY |GLOB |0    |UNDEF 
|__dtrace_dsax___qdna_return
[18]    |         0|       0|NOTY |GLOB |0    |UNDEF  |__dtrace_dsax___ufncall

2. xgoto0.o:

nm xgoto0.o | grep _dtrace
[18]    |         0|       0|NOTY |GLOB |0    |UNDEF  |__dtrace_dsax___af_return

3. exmgr.o:

nm exmgr.o | grep _dtrace
[22]    |         0|       0|NOTY |GLOB |0    |UNDEF  |__dtrace_dsax___af_return

4. dsax.o:

nm dsax.o | grep _dtrace
[50]    |         0|       0|NOTY |GLOB |0    |IGNORE |__dtrace_dsax___af_entry
[60]    |         0|       0|NOTY |GLOB |0    |IGNORE |__dtrace_dsax___af_return
[49]    |         0|       0|NOTY |GLOB |0    |IGNORE |__dtrace_dsax___if_entry
[59]    |         0|       0|NOTY |GLOB |0    |IGNORE |__dtrace_dsax___if_return
[51]    |         0|       0|NOTY |GLOB |0    |IGNORE
|__dtrace_dsax___qdna_entry
[67]    |         0|       0|NOTY |GLOB |0    |IGNORE
|__dtrace_dsax___qdna_return
[62]    |         0|       0|NOTY |GLOB |0    |IGNORE |__dtrace_dsax___ufncall

However, when I link my final program, I am still getting the same error:

gcc -g -DOSVER=11 -I$SAXDIR/src/include  -D__REENTRANT -DSYS=SYSSOLIX86
-D_ALL_SOURCE -funsigned-char  -o $SAXDIR/bin/appl ./exec/main.o 
$SAXDIR/lib/apiface_d.o  $SAXDIR/lib/libsax.a -L$SAXDIR/lib -ltrace -lsaxipc
-lfs4clt -lfs4 -lm -ldl -lcurses -lcrypt -lsocket -lnsl -lrt
Undefined			first referenced
  symbol  			    in file
__dtrace_dsax___af_return           $SAXDIR/lib/libsax.a(exmgr.o)

So, why can''t ld resolve my symbol?

If that matters:
% uname -a
SunOS lokrum 5.11 snv_20 i86pc i386 i86pc

% gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with: /builds/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-multilib --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

% ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.502

TIA and bye, Dragan

-- 
Dragan Cvetkovic,

To be or not to be is true. G. Boole    No it isn''t.  L. E. J. Brouwer