dtrace discuss - Mar 2006 - question about compile application with DTrace probes

Hi,

I''m trying to insert some DTrace probes into the application by
following the steps as:

1. compiled "appprobe.d" including the provider/probes definition by
runing
  dtrace -G -32 -s appprobe.d src1.o src2.o
  (src1.c is the source code added with the DTrace probes, ans src2 are
have the functions/variables implementation/definitions that src1.c need
to call from.

2. cc -o test appprobe.d src1.o src2.o
   ---- Here I got error as bellow and the compilation failed:
     Undefined symbol: __dtrace_appprobe___probe1()(first referenced in
file src1.o)

Any comment on why the compilation failed?
Thanks in advance for your information, and could you please send to my
email directly since I''m not currently in this email alias.


Regards,
Jenny
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen
wrote:
> Hi,
> 
> I''m trying to insert some DTrace probes into the application by
> following the steps as:
> 
> 1. compiled "appprobe.d" including the provider/probes definition
by runing
>   dtrace -G -32 -s appprobe.d src1.o src2.o
>   (src1.c is the source code added with the DTrace probes, ans src2 are
> have the functions/variables implementation/definitions that src1.c need
> to call from.
> 
> 2. cc -o test appprobe.d src1.o src2.o
                ^^^^^^^^^^ appprobe.o?
>    ---- Here I got error as bellow and the compilation failed:
>      Undefined symbol: __dtrace_appprobe___probe1()(first referenced in
> file src1.o)
> 
> Any comment on why the compilation failed?
> Thanks in advance for your information, and could you please send to my
> email directly since I''m not currently in this email alias.
It looks like src1.o didn''t get properly munged by dtrace;  could you
give the full sequence of steps, with all of the output?

The steps should be something like:

cc -c src1.c
cc -c src2.c
dtrace -G -32 -s appprobe.d src1.o src2.o
cc -o test approbe.o src1.o src2.o

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

Hi,

The steps & output were as bellow:

Jonathan Adams wrote On 03/08/06 14:43,:
> On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen wrote:
> 
>>Hi,
>>
>>I''m trying to insert some DTrace probes into the application by
>>following the steps as:
>>
>>1. compiled "appprobe.d" including the provider/probes
definition by runing
>>  dtrace -G -32 -s appprobe.d src1.o src2.o
>>  (src1.c is the source code added with the DTrace probes, ans src2 are
>>have the functions/variables implementation/definitions that src1.c need
>>to call from.
>>
>>2. cc -o test appprobe.d src1.o src2.o
> 
>                 ^^^^^^^^^^ appprobe.o?
> 
> 
>>   ---- Here I got error as bellow and the compilation failed:
>>     Undefined symbol: __dtrace_appprobe___probe1()(first referenced in
>>file src1.o)
>>
>>Any comment on why the compilation failed?
>>Thanks in advance for your information, and could you please send to my
>>email directly since I''m not currently in this email alias.
> 
> 
> It looks like src1.o didn''t get properly munged by dtrace;  could
you
> give the full sequence of steps, with all of the output?
> 
> The steps should be something like:
> 
> cc -c src1.c
> cc -c src2.c
The two steps generated src1.o, src2.o
> dtrace -G -32 -s appprobe.d src1.o src2.o
This step generated appprobe.o
> cc -o test approbe.o src1.o src2.o
--> errors generated here:

Undefined                       first referenced
 symbol                             in file
cos                                 item_func.o
exp                                 item_func.o
log                                 item_func.o
...
 __dtrace_appprobe___probe1()	    src1.o
...



Thanks!
Jenny

> Cheers,
> - jonathan
> 
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

Hi,

In the last step, I have all the other undefined symbols solved, but
just the "__dtrace_appprobe___probe1()" left.

This is version: Solaris Nevada snv_34 SPARC, any comment/feedback on
this problem?


Thanks!
Jenny

Luojia Chen wrote On 03/08/06 15:28,:
> Hi,
> 
> The steps & output were as bellow:
> 
> Jonathan Adams wrote On 03/08/06 14:43,:
> 
>>On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen wrote:
>>
>>
>>>Hi,
>>>
>>>I''m trying to insert some DTrace probes into the
application by
>>>following the steps as:
>>>
>>>1. compiled "appprobe.d" including the provider/probes
definition by runing
>>> dtrace -G -32 -s appprobe.d src1.o src2.o
>>> (src1.c is the source code added with the DTrace probes, ans src2
are
>>>have the functions/variables implementation/definitions that src1.c
need
>>>to call from.
>>>
>>>2. cc -o test appprobe.d src1.o src2.o
>>
>>                ^^^^^^^^^^ appprobe.o?
>>
>>
>>
>>>  ---- Here I got error as bellow and the compilation failed:
>>>    Undefined symbol: __dtrace_appprobe___probe1()(first referenced
in
>>>file src1.o)
>>>
>>>Any comment on why the compilation failed?
>>>Thanks in advance for your information, and could you please send to
my
>>>email directly since I''m not currently in this email alias.
>>
>>
>>It looks like src1.o didn''t get properly munged by dtrace; 
could you
>>give the full sequence of steps, with all of the output?
>>
>>The steps should be something like:
>>
>>cc -c src1.c
>>cc -c src2.c
> 
> 
> The two steps generated src1.o, src2.o
> 
> 
>>dtrace -G -32 -s appprobe.d src1.o src2.o
> 
> 
> This step generated appprobe.o
> 
> 
>>cc -o test approbe.o src1.o src2.o
> 
> 
> --> errors generated here:
> 
> Undefined                       first referenced
>  symbol                             in file
> cos                                 item_func.o
> exp                                 item_func.o
> log                                 item_func.o
> ...
>  __dtrace_appprobe___probe1()	    src1.o
> ...
> 
> 
> 
> Thanks!
> Jenny
> 
> 
> 
>>Cheers,
>>- jonathan
>>
> 
> 
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

Hi Jenny,

Running dtrace -G on src1.o should have removed any references to symbols
starting with __dtrace. Can you send me the output of ''elfdump -s
src1.o''
before and after you run it through dtrace -G?

Can you also send the output of ''ld -V''?

Thanks.

Adam

On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen
wrote:
> Hi,
> 
> In the last step, I have all the other undefined symbols solved, but
> just the "__dtrace_appprobe___probe1()" left.
> 
> This is version: Solaris Nevada snv_34 SPARC, any comment/feedback on
> this problem?
> 
> 
> Thanks!
> Jenny
> 
> Luojia Chen wrote On 03/08/06 15:28,:
> > Hi,
> > 
> > The steps & output were as bellow:
> > 
> > Jonathan Adams wrote On 03/08/06 14:43,:
> > 
> >>On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>I''m trying to insert some DTrace probes into the
application by
> >>>following the steps as:
> >>>
> >>>1. compiled "appprobe.d" including the
provider/probes definition by runing
> >>> dtrace -G -32 -s appprobe.d src1.o src2.o
> >>> (src1.c is the source code added with the DTrace probes, ans
src2 are
> >>>have the functions/variables implementation/definitions that
src1.c need
> >>>to call from.
> >>>
> >>>2. cc -o test appprobe.d src1.o src2.o
> >>
> >>                ^^^^^^^^^^ appprobe.o?
> >>
> >>
> >>
> >>>  ---- Here I got error as bellow and the compilation failed:
> >>>    Undefined symbol: __dtrace_appprobe___probe1()(first
referenced in
> >>>file src1.o)
> >>>
> >>>Any comment on why the compilation failed?
> >>>Thanks in advance for your information, and could you please
send to my
> >>>email directly since I''m not currently in this email
alias.
> >>
> >>
> >>It looks like src1.o didn''t get properly munged by dtrace;
could you
> >>give the full sequence of steps, with all of the output?
> >>
> >>The steps should be something like:
> >>
> >>cc -c src1.c
> >>cc -c src2.c
> > 
> > 
> > The two steps generated src1.o, src2.o
> > 
> > 
> >>dtrace -G -32 -s appprobe.d src1.o src2.o
> > 
> > 
> > This step generated appprobe.o
> > 
> > 
> >>cc -o test approbe.o src1.o src2.o
> > 
> > 
> > --> errors generated here:
> > 
> > Undefined                       first referenced
> >  symbol                             in file
> > cos                                 item_func.o
> > exp                                 item_func.o
> > log                                 item_func.o
> > ...
> >  __dtrace_appprobe___probe1()	    src1.o
> > ...
> > 
> > 
> > 
> > Thanks!
> > Jenny
> > 
> > 
> > 
> >>Cheers,
> >>- jonathan
> >>
> > 
> > 
> 
> -- 
> 
>    Jenny Chen
>    Software Engineer
>    Market Development Engineering
>    v-mail:(510) 574-7149
>    SUN Microsystems
> 
> 
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Hi Jenny,

Thanks for sending the output I asked for.

The problem you''re seeing is related to C++ symbol name mangling (the
example
you gave would more accurately have been ''gcc -c src1.cc'' not
''cc -c src1.c''
-- a fairly significant difference). gcc was renaming your symbol from
__dtrace_appprobe___probe1 to _Z35__dtrace_appprobe___probe1; dtrace -G
therefore wasn''t identifying it which caused the linker to fail.

Take a look at my post to the discussion forum on how to use the new USDT
headergen feature to embed probes:

  http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815

You should also make sure you''re using the Solaris linker and not the
gnu
linker. There are some modifications we made to support USDT which
haven''t
been implemented yet in the gnu linker.

Adam

On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal
wrote:
> Hi Jenny,
> 
> Running dtrace -G on src1.o should have removed any references to symbols
> starting with __dtrace. Can you send me the output of ''elfdump -s
src1.o''
> before and after you run it through dtrace -G?
> 
> Can you also send the output of ''ld -V''?
> 
> Thanks.
> 
> Adam
> 
> On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen wrote:
> > Hi,
> > 
> > In the last step, I have all the other undefined symbols solved, but
> > just the "__dtrace_appprobe___probe1()" left.
> > 
> > This is version: Solaris Nevada snv_34 SPARC, any comment/feedback on
> > this problem?
> > 
> > 
> > Thanks!
> > Jenny
> > 
> > Luojia Chen wrote On 03/08/06 15:28,:
> > > Hi,
> > > 
> > > The steps & output were as bellow:
> > > 
> > > Jonathan Adams wrote On 03/08/06 14:43,:
> > > 
> > >>On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen wrote:
> > >>
> > >>
> > >>>Hi,
> > >>>
> > >>>I''m trying to insert some DTrace probes into the
application by
> > >>>following the steps as:
> > >>>
> > >>>1. compiled "appprobe.d" including the
provider/probes definition by runing
> > >>> dtrace -G -32 -s appprobe.d src1.o src2.o
> > >>> (src1.c is the source code added with the DTrace probes,
ans src2 are
> > >>>have the functions/variables implementation/definitions
that src1.c need
> > >>>to call from.
> > >>>
> > >>>2. cc -o test appprobe.d src1.o src2.o
> > >>
> > >>                ^^^^^^^^^^ appprobe.o?
> > >>
> > >>
> > >>
> > >>>  ---- Here I got error as bellow and the compilation
failed:
> > >>>    Undefined symbol: __dtrace_appprobe___probe1()(first
referenced in
> > >>>file src1.o)
> > >>>
> > >>>Any comment on why the compilation failed?
> > >>>Thanks in advance for your information, and could you
please send to my
> > >>>email directly since I''m not currently in this
email alias.
> > >>
> > >>
> > >>It looks like src1.o didn''t get properly munged by
dtrace;  could you
> > >>give the full sequence of steps, with all of the output?
> > >>
> > >>The steps should be something like:
> > >>
> > >>cc -c src1.c
> > >>cc -c src2.c
> > > 
> > > 
> > > The two steps generated src1.o, src2.o
> > > 
> > > 
> > >>dtrace -G -32 -s appprobe.d src1.o src2.o
> > > 
> > > 
> > > This step generated appprobe.o
> > > 
> > > 
> > >>cc -o test approbe.o src1.o src2.o
> > > 
> > > 
> > > --> errors generated here:
> > > 
> > > Undefined                       first referenced
> > >  symbol                             in file
> > > cos                                 item_func.o
> > > exp                                 item_func.o
> > > log                                 item_func.o
> > > ...
> > >  __dtrace_appprobe___probe1()	    src1.o
> > > ...
> > > 
> > > 
> > > 
> > > Thanks!
> > > Jenny
> > > 
> > > 
> > > 
> > >>Cheers,
> > >>- jonathan
> > >>
> > > 
> > > 
> > 
> > -- 
> > 
> >    Jenny Chen
> >    Software Engineer
> >    Market Development Engineering
> >    v-mail:(510) 574-7149
> >    SUN Microsystems
> > 
> > 
> > 
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
> 
> -- 
> Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Adm,

Adam Leventhal wrote On 03/09/06 11:10,:
> Hi Jenny,
> 
> Thanks for sending the output I asked for.
> 
> The problem you''re seeing is related to C++ symbol name mangling
(the example
> you gave would more accurately have been ''gcc -c src1.cc''
not ''cc -c src1.c''
> -- a fairly significant difference). gcc was renaming your symbol from
> __dtrace_appprobe___probe1 to _Z35__dtrace_appprobe___probe1; dtrace -G
> therefore wasn''t identifying it which caused the linker to fail.
I just tried with our venus compiler, but the __dtrace_appprobe___probe1
was changed to be __1cbJ__dtrace_appprobe___probe1 in my case, causing
the same failure?


Thanks,
Jenny

> Take a look at my post to the discussion forum on how to use the new USDT
> headergen feature to embed probes:
> 
>   http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815
> 
> You should also make sure you''re using the Solaris linker and not
the gnu
> linker. There are some modifications we made to support USDT which
haven''t
> been implemented yet in the gnu linker.
> 
> Adam
> 
> On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal wrote:
> 
>>Hi Jenny,
>>
>>Running dtrace -G on src1.o should have removed any references to
symbols
>>starting with __dtrace. Can you send me the output of ''elfdump
-s src1.o''
>>before and after you run it through dtrace -G?
>>
>>Can you also send the output of ''ld -V''?
>>
>>Thanks.
>>
>>Adam
>>
>>On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen wrote:
>>
>>>Hi,
>>>
>>>In the last step, I have all the other undefined symbols solved, but
>>>just the "__dtrace_appprobe___probe1()" left.
>>>
>>>This is version: Solaris Nevada snv_34 SPARC, any comment/feedback
on
>>>this problem?
>>>
>>>
>>>Thanks!
>>>Jenny
>>>
>>>Luojia Chen wrote On 03/08/06 15:28,:
>>>
>>>>Hi,
>>>>
>>>>The steps & output were as bellow:
>>>>
>>>>Jonathan Adams wrote On 03/08/06 14:43,:
>>>>
>>>>
>>>>>On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I''m trying to insert some DTrace probes into
the application by
>>>>>>following the steps as:
>>>>>>
>>>>>>1. compiled "appprobe.d" including the
provider/probes definition by runing
>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
>>>>>>(src1.c is the source code added with the DTrace probes,
ans src2 are
>>>>>>have the functions/variables implementation/definitions
that src1.c need
>>>>>>to call from.
>>>>>>
>>>>>>2. cc -o test appprobe.d src1.o src2.o
>>>>>
>>>>>               ^^^^^^^^^^ appprobe.o?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ---- Here I got error as bellow and the compilation
failed:
>>>>>>   Undefined symbol: __dtrace_appprobe___probe1()(first
referenced in
>>>>>>file src1.o)
>>>>>>
>>>>>>Any comment on why the compilation failed?
>>>>>>Thanks in advance for your information, and could you
please send to my
>>>>>>email directly since I''m not currently in this
email alias.
>>>>>
>>>>>
>>>>>It looks like src1.o didn''t get properly munged by
dtrace;  could you
>>>>>give the full sequence of steps, with all of the output?
>>>>>
>>>>>The steps should be something like:
>>>>>
>>>>>cc -c src1.c
>>>>>cc -c src2.c
>>>>
>>>>
>>>>The two steps generated src1.o, src2.o
>>>>
>>>>
>>>>
>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
>>>>
>>>>
>>>>This step generated appprobe.o
>>>>
>>>>
>>>>
>>>>>cc -o test approbe.o src1.o src2.o
>>>>
>>>>
>>>>--> errors generated here:
>>>>
>>>>Undefined                       first referenced
>>>> symbol                             in file
>>>>cos                                 item_func.o
>>>>exp                                 item_func.o
>>>>log                                 item_func.o
>>>>...
>>>> __dtrace_appprobe___probe1()	    src1.o
>>>>...
>>>>
>>>>
>>>>
>>>>Thanks!
>>>>Jenny
>>>>
>>>>
>>>>
>>>>
>>>>>Cheers,
>>>>>- jonathan
>>>>>
>>>>
>>>>
>>>-- 
>>>
>>>   Jenny Chen
>>>   Software Engineer
>>>   Market Development Engineering
>>>   v-mail:(510) 574-7149
>>>   SUN Microsystems
>>>
>>>
>>>
>>>_______________________________________________
>>>dtrace-discuss mailing list
>>>dtrace-discuss at opensolaris.org
>>
>>-- 
>>Adam Leventhal, Solaris Kernel Development      
http://blogs.sun.com/ahl
>>_______________________________________________
>>dtrace-discuss mailing list
>>dtrace-discuss at opensolaris.org
> 
> 
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

Right. Since you''re using C++ you need to follow the new directions in
the
post I mentioned:

    http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815

Adam

On Thu, Mar 09, 2006 at 12:12:00PM -0800, Luojia Chen
wrote:
> Adm,
> 
> Adam Leventhal wrote On 03/09/06 11:10,:
> > Hi Jenny,
> > 
> > Thanks for sending the output I asked for.
> > 
> > The problem you''re seeing is related to C++ symbol name
mangling (the example
> > you gave would more accurately have been ''gcc -c
src1.cc'' not ''cc -c src1.c''
> > -- a fairly significant difference). gcc was renaming your symbol from
> > __dtrace_appprobe___probe1 to _Z35__dtrace_appprobe___probe1; dtrace
-G
> > therefore wasn''t identifying it which caused the linker to
fail.
> 
> I just tried with our venus compiler, but the __dtrace_appprobe___probe1
> was changed to be __1cbJ__dtrace_appprobe___probe1 in my case, causing
> the same failure?
> 
> 
> Thanks,
> Jenny
> 
> 
> > Take a look at my post to the discussion forum on how to use the new
USDT
> > headergen feature to embed probes:
> > 
> >  
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815
> > 
> > You should also make sure you''re using the Solaris linker and
not the gnu
> > linker. There are some modifications we made to support USDT which
haven''t
> > been implemented yet in the gnu linker.
> > 
> > Adam
> > 
> > On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal wrote:
> > 
> >>Hi Jenny,
> >>
> >>Running dtrace -G on src1.o should have removed any references to
symbols
> >>starting with __dtrace. Can you send me the output of
''elfdump -s src1.o''
> >>before and after you run it through dtrace -G?
> >>
> >>Can you also send the output of ''ld -V''?
> >>
> >>Thanks.
> >>
> >>Adam
> >>
> >>On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen wrote:
> >>
> >>>Hi,
> >>>
> >>>In the last step, I have all the other undefined symbols
solved, but
> >>>just the "__dtrace_appprobe___probe1()" left.
> >>>
> >>>This is version: Solaris Nevada snv_34 SPARC, any
comment/feedback on
> >>>this problem?
> >>>
> >>>
> >>>Thanks!
> >>>Jenny
> >>>
> >>>Luojia Chen wrote On 03/08/06 15:28,:
> >>>
> >>>>Hi,
> >>>>
> >>>>The steps & output were as bellow:
> >>>>
> >>>>Jonathan Adams wrote On 03/08/06 14:43,:
> >>>>
> >>>>
> >>>>>On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen
wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>I''m trying to insert some DTrace probes
into the application by
> >>>>>>following the steps as:
> >>>>>>
> >>>>>>1. compiled "appprobe.d" including the
provider/probes definition by runing
> >>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> >>>>>>(src1.c is the source code added with the DTrace
probes, ans src2 are
> >>>>>>have the functions/variables
implementation/definitions that src1.c need
> >>>>>>to call from.
> >>>>>>
> >>>>>>2. cc -o test appprobe.d src1.o src2.o
> >>>>>
> >>>>>               ^^^^^^^^^^ appprobe.o?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> ---- Here I got error as bellow and the
compilation failed:
> >>>>>>   Undefined symbol:
__dtrace_appprobe___probe1()(first referenced in
> >>>>>>file src1.o)
> >>>>>>
> >>>>>>Any comment on why the compilation failed?
> >>>>>>Thanks in advance for your information, and could
you please send to my
> >>>>>>email directly since I''m not currently in
this email alias.
> >>>>>
> >>>>>
> >>>>>It looks like src1.o didn''t get properly
munged by dtrace;  could you
> >>>>>give the full sequence of steps, with all of the
output?
> >>>>>
> >>>>>The steps should be something like:
> >>>>>
> >>>>>cc -c src1.c
> >>>>>cc -c src2.c
> >>>>
> >>>>
> >>>>The two steps generated src1.o, src2.o
> >>>>
> >>>>
> >>>>
> >>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> >>>>
> >>>>
> >>>>This step generated appprobe.o
> >>>>
> >>>>
> >>>>
> >>>>>cc -o test approbe.o src1.o src2.o
> >>>>
> >>>>
> >>>>--> errors generated here:
> >>>>
> >>>>Undefined                       first referenced
> >>>> symbol                             in file
> >>>>cos                                 item_func.o
> >>>>exp                                 item_func.o
> >>>>log                                 item_func.o
> >>>>...
> >>>> __dtrace_appprobe___probe1()	    src1.o
> >>>>...
> >>>>
> >>>>
> >>>>
> >>>>Thanks!
> >>>>Jenny
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Cheers,
> >>>>>- jonathan
> >>>>>
> >>>>
> >>>>
> >>>-- 
> >>>
> >>>   Jenny Chen
> >>>   Software Engineer
> >>>   Market Development Engineering
> >>>   v-mail:(510) 574-7149
> >>>   SUN Microsystems
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>dtrace-discuss mailing list
> >>>dtrace-discuss at opensolaris.org
> >>
> >>-- 
> >>Adam Leventhal, Solaris Kernel Development      
http://blogs.sun.com/ahl
> >>_______________________________________________
> >>dtrace-discuss mailing list
> >>dtrace-discuss at opensolaris.org
> > 
> > 
> 
> -- 
> 
>    Jenny Chen
>    Software Engineer
>    Market Development Engineering
>    v-mail:(510) 574-7149
>    SUN Microsystems
> 
> 
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Yes, it works!


Thanks!
Jenny




Adam Leventhal wrote On 03/09/06 13:19,:
> Right. Since you''re using C++ you need to follow the new
directions in the
> post I mentioned:
> 
>     http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815
> 
> Adam
> 
> On Thu, Mar 09, 2006 at 12:12:00PM -0800, Luojia Chen wrote:
> 
>>Adm,
>>
>>Adam Leventhal wrote On 03/09/06 11:10,:
>>
>>>Hi Jenny,
>>>
>>>Thanks for sending the output I asked for.
>>>
>>>The problem you''re seeing is related to C++ symbol name
mangling (the example
>>>you gave would more accurately have been ''gcc -c
src1.cc'' not ''cc -c src1.c''
>>>-- a fairly significant difference). gcc was renaming your symbol
from
>>>__dtrace_appprobe___probe1 to _Z35__dtrace_appprobe___probe1; dtrace
-G
>>>therefore wasn''t identifying it which caused the linker to
fail.
>>
>>I just tried with our venus compiler, but the __dtrace_appprobe___probe1
>>was changed to be __1cbJ__dtrace_appprobe___probe1 in my case, causing
>>the same failure?
>>
>>
>>Thanks,
>>Jenny
>>
>>
>>
>>>Take a look at my post to the discussion forum on how to use the new
USDT
>>>headergen feature to embed probes:
>>>
>>> 
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815
>>>
>>>You should also make sure you''re using the Solaris linker
and not the gnu
>>>linker. There are some modifications we made to support USDT which
haven''t
>>>been implemented yet in the gnu linker.
>>>
>>>Adam
>>>
>>>On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal wrote:
>>>
>>>
>>>>Hi Jenny,
>>>>
>>>>Running dtrace -G on src1.o should have removed any references
to symbols
>>>>starting with __dtrace. Can you send me the output of
''elfdump -s src1.o''
>>>>before and after you run it through dtrace -G?
>>>>
>>>>Can you also send the output of ''ld -V''?
>>>>
>>>>Thanks.
>>>>
>>>>Adam
>>>>
>>>>On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>In the last step, I have all the other undefined symbols
solved, but
>>>>>just the "__dtrace_appprobe___probe1()" left.
>>>>>
>>>>>This is version: Solaris Nevada snv_34 SPARC, any
comment/feedback on
>>>>>this problem?
>>>>>
>>>>>
>>>>>Thanks!
>>>>>Jenny
>>>>>
>>>>>Luojia Chen wrote On 03/08/06 15:28,:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>The steps & output were as bellow:
>>>>>>
>>>>>>Jonathan Adams wrote On 03/08/06 14:43,:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia
Chen wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>I''m trying to insert some DTrace probes
into the application by
>>>>>>>>following the steps as:
>>>>>>>>
>>>>>>>>1. compiled "appprobe.d" including the
provider/probes definition by runing
>>>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
>>>>>>>>(src1.c is the source code added with the DTrace
probes, ans src2 are
>>>>>>>>have the functions/variables
implementation/definitions that src1.c need
>>>>>>>>to call from.
>>>>>>>>
>>>>>>>>2. cc -o test appprobe.d src1.o src2.o
>>>>>>>
>>>>>>>              ^^^^^^^^^^ appprobe.o?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>---- Here I got error as bellow and the
compilation failed:
>>>>>>>>  Undefined symbol:
__dtrace_appprobe___probe1()(first referenced in
>>>>>>>>file src1.o)
>>>>>>>>
>>>>>>>>Any comment on why the compilation failed?
>>>>>>>>Thanks in advance for your information, and
could you please send to my
>>>>>>>>email directly since I''m not currently
in this email alias.
>>>>>>>
>>>>>>>
>>>>>>>It looks like src1.o didn''t get properly
munged by dtrace;  could you
>>>>>>>give the full sequence of steps, with all of the
output?
>>>>>>>
>>>>>>>The steps should be something like:
>>>>>>>
>>>>>>>cc -c src1.c
>>>>>>>cc -c src2.c
>>>>>>
>>>>>>
>>>>>>The two steps generated src1.o, src2.o
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
>>>>>>
>>>>>>
>>>>>>This step generated appprobe.o
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>cc -o test approbe.o src1.o src2.o
>>>>>>
>>>>>>
>>>>>>--> errors generated here:
>>>>>>
>>>>>>Undefined                       first referenced
>>>>>>symbol                             in file
>>>>>>cos                                 item_func.o
>>>>>>exp                                 item_func.o
>>>>>>log                                 item_func.o
>>>>>>...
>>>>>>__dtrace_appprobe___probe1()	    src1.o
>>>>>>...
>>>>>>
>>>>>>
>>>>>>
>>>>>>Thanks!
>>>>>>Jenny
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Cheers,
>>>>>>>- jonathan
>>>>>>>
>>>>>>
>>>>>>
>>>>>-- 
>>>>>
>>>>>  Jenny Chen
>>>>>  Software Engineer
>>>>>  Market Development Engineering
>>>>>  v-mail:(510) 574-7149
>>>>>  SUN Microsystems
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>dtrace-discuss mailing list
>>>>>dtrace-discuss at opensolaris.org
>>>>
>>>>-- 
>>>>Adam Leventhal, Solaris Kernel Development      
http://blogs.sun.com/ahl
>>>>_______________________________________________
>>>>dtrace-discuss mailing list
>>>>dtrace-discuss at opensolaris.org
>>>
>>>
>>-- 
>>
>>   Jenny Chen
>>   Software Engineer
>>   Market Development Engineering
>>   v-mail:(510) 574-7149
>>   SUN Microsystems
>>
>>
> 
> 
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

Great to hear. Thanks for validating the new methodology.

Adam

On Thu, Mar 09, 2006 at 03:33:14PM -0800, Luojia Chen
wrote:
> Yes, it works!
> 
> 
> Thanks!
> Jenny
> 
> 
> 
> 
> Adam Leventhal wrote On 03/09/06 13:19,:
> > Right. Since you''re using C++ you need to follow the new
directions in the
> > post I mentioned:
> > 
> >    
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815
> > 
> > Adam
> > 
> > On Thu, Mar 09, 2006 at 12:12:00PM -0800, Luojia Chen wrote:
> > 
> >>Adm,
> >>
> >>Adam Leventhal wrote On 03/09/06 11:10,:
> >>
> >>>Hi Jenny,
> >>>
> >>>Thanks for sending the output I asked for.
> >>>
> >>>The problem you''re seeing is related to C++ symbol
name mangling (the example
> >>>you gave would more accurately have been ''gcc -c
src1.cc'' not ''cc -c src1.c''
> >>>-- a fairly significant difference). gcc was renaming your
symbol from
> >>>__dtrace_appprobe___probe1 to _Z35__dtrace_appprobe___probe1;
dtrace -G
> >>>therefore wasn''t identifying it which caused the
linker to fail.
> >>
> >>I just tried with our venus compiler, but the
__dtrace_appprobe___probe1
> >>was changed to be __1cbJ__dtrace_appprobe___probe1 in my case,
causing
> >>the same failure?
> >>
> >>
> >>Thanks,
> >>Jenny
> >>
> >>
> >>
> >>>Take a look at my post to the discussion forum on how to use
the new USDT
> >>>headergen feature to embed probes:
> >>>
> >>> 
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815
> >>>
> >>>You should also make sure you''re using the Solaris
linker and not the gnu
> >>>linker. There are some modifications we made to support USDT
which haven''t
> >>>been implemented yet in the gnu linker.
> >>>
> >>>Adam
> >>>
> >>>On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal wrote:
> >>>
> >>>
> >>>>Hi Jenny,
> >>>>
> >>>>Running dtrace -G on src1.o should have removed any
references to symbols
> >>>>starting with __dtrace. Can you send me the output of
''elfdump -s src1.o''
> >>>>before and after you run it through dtrace -G?
> >>>>
> >>>>Can you also send the output of ''ld -V''?
> >>>>
> >>>>Thanks.
> >>>>
> >>>>Adam
> >>>>
> >>>>On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen
wrote:
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>In the last step, I have all the other undefined
symbols solved, but
> >>>>>just the "__dtrace_appprobe___probe1()" left.
> >>>>>
> >>>>>This is version: Solaris Nevada snv_34 SPARC, any
comment/feedback on
> >>>>>this problem?
> >>>>>
> >>>>>
> >>>>>Thanks!
> >>>>>Jenny
> >>>>>
> >>>>>Luojia Chen wrote On 03/08/06 15:28,:
> >>>>>
> >>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>The steps & output were as bellow:
> >>>>>>
> >>>>>>Jonathan Adams wrote On 03/08/06 14:43,:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>On Wed, Mar 08, 2006 at 02:32:40PM -0800,
Luojia Chen wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Hi,
> >>>>>>>>
> >>>>>>>>I''m trying to insert some DTrace
probes into the application by
> >>>>>>>>following the steps as:
> >>>>>>>>
> >>>>>>>>1. compiled "appprobe.d"
including the provider/probes definition by runing
> >>>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> >>>>>>>>(src1.c is the source code added with the
DTrace probes, ans src2 are
> >>>>>>>>have the functions/variables
implementation/definitions that src1.c need
> >>>>>>>>to call from.
> >>>>>>>>
> >>>>>>>>2. cc -o test appprobe.d src1.o src2.o
> >>>>>>>
> >>>>>>>              ^^^^^^^^^^ appprobe.o?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>---- Here I got error as bellow and the
compilation failed:
> >>>>>>>>  Undefined symbol:
__dtrace_appprobe___probe1()(first referenced in
> >>>>>>>>file src1.o)
> >>>>>>>>
> >>>>>>>>Any comment on why the compilation failed?
> >>>>>>>>Thanks in advance for your information, and
could you please send to my
> >>>>>>>>email directly since I''m not
currently in this email alias.
> >>>>>>>
> >>>>>>>
> >>>>>>>It looks like src1.o didn''t get
properly munged by dtrace;  could you
> >>>>>>>give the full sequence of steps, with all of
the output?
> >>>>>>>
> >>>>>>>The steps should be something like:
> >>>>>>>
> >>>>>>>cc -c src1.c
> >>>>>>>cc -c src2.c
> >>>>>>
> >>>>>>
> >>>>>>The two steps generated src1.o, src2.o
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> >>>>>>
> >>>>>>
> >>>>>>This step generated appprobe.o
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>cc -o test approbe.o src1.o src2.o
> >>>>>>
> >>>>>>
> >>>>>>--> errors generated here:
> >>>>>>
> >>>>>>Undefined                       first referenced
> >>>>>>symbol                             in file
> >>>>>>cos                                 item_func.o
> >>>>>>exp                                 item_func.o
> >>>>>>log                                 item_func.o
> >>>>>>...
> >>>>>>__dtrace_appprobe___probe1()	    src1.o
> >>>>>>...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Thanks!
> >>>>>>Jenny
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Cheers,
> >>>>>>>- jonathan
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>-- 
> >>>>>
> >>>>>  Jenny Chen
> >>>>>  Software Engineer
> >>>>>  Market Development Engineering
> >>>>>  v-mail:(510) 574-7149
> >>>>>  SUN Microsystems
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>dtrace-discuss mailing list
> >>>>>dtrace-discuss at opensolaris.org
> >>>>
> >>>>-- 
> >>>>Adam Leventhal, Solaris Kernel Development      
http://blogs.sun.com/ahl
> >>>>_______________________________________________
> >>>>dtrace-discuss mailing list
> >>>>dtrace-discuss at opensolaris.org
> >>>
> >>>
> >>-- 
> >>
> >>   Jenny Chen
> >>   Software Engineer
> >>   Market Development Engineering
> >>   v-mail:(510) 574-7149
> >>   SUN Microsystems
> >>
> >>
> > 
> > 
> 
> -- 
> 
>    Jenny Chen
>    Software Engineer
>    Market Development Engineering
>    v-mail:(510) 574-7149
>    SUN Microsystems
> 
> 
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Hi,

If I have a DTrace probe defined with some parameters like:
	probe probe1(int, char)

And when insert the probe somewhere into the application, it may need
call some functions/opteration to get the parameters for the probe, like
...
int x = XYZ + ABC; ---line1
char y = getY();   ---line2
PROVIDER_PROBE1(x,y);
...

However,the problem here is: in order to insert the probe1 to the
application, we have to add line1,2 to get the parameters for the probe,
which can be a *big overhead* to the application.

Is there some way to solve this problem? Something like:

...
if(DTrace probe1 is invoked)
int x = XYZ + ABC; ---line1
char y = getY();   ---line2
PROVIDER_PROBE1(x,y);
...

So that the line1 and line 2 don''t have to be implemented every time
even if the probe1 doesn''t be invoked?

Thanks for your information in advance!


Jenny





Jonathan Adams wrote On 03/08/06 14:43,:
> On Wed, Mar 08, 2006 at 02:32:40PM -0800, Luojia Chen wrote:
> 
>>Hi,
>>
>>I''m trying to insert some DTrace probes into the application by
>>following the steps as:
>>
>>1. compiled "appprobe.d" including the provider/probes
definition by runing
>>  dtrace -G -32 -s appprobe.d src1.o src2.o
>>  (src1.c is the source code added with the DTrace probes, ans src2 are
>>have the functions/variables implementation/definitions that src1.c need
>>to call from.
>>
>>2. cc -o test appprobe.d src1.o src2.o
> 
>                 ^^^^^^^^^^ appprobe.o?
> 
> 
>>   ---- Here I got error as bellow and the compilation failed:
>>     Undefined symbol: __dtrace_appprobe___probe1()(first referenced in
>>file src1.o)
>>
>>Any comment on why the compilation failed?
>>Thanks in advance for your information, and could you please send to my
>>email directly since I''m not currently in this email alias.
> 
> 
> It looks like src1.o didn''t get properly munged by dtrace;  could
you
> give the full sequence of steps, with all of the output?
> 
> The steps should be something like:
> 
> cc -c src1.c
> cc -c src2.c
> dtrace -G -32 -s appprobe.d src1.o src2.o
> cc -o test approbe.o src1.o src2.o
> 
> Cheers,
> - jonathan
> 
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

How convenient that Adam just fixed this bug yesterday:

6405927 USDT is-enabled probes

This will give you exactly what you want.  It will be available in build
38.

- Eric

On Fri, Mar 31, 2006 at 11:39:03AM -0800, Luojia Chen
wrote:
> Hi,
> 
> If I have a DTrace probe defined with some parameters like:
> 	probe probe1(int, char)
> 
> And when insert the probe somewhere into the application, it may need
> call some functions/opteration to get the parameters for the probe, like
> ...
> int x = XYZ + ABC; ---line1
> char y = getY();   ---line2
> PROVIDER_PROBE1(x,y);
> ...
> 
> However,the problem here is: in order to insert the probe1 to the
> application, we have to add line1,2 to get the parameters for the probe,
> which can be a *big overhead* to the application.
> 
> Is there some way to solve this problem? Something like:
> 
> ...
> if(DTrace probe1 is invoked)
> int x = XYZ + ABC; ---line1
> char y = getY();   ---line2
> PROVIDER_PROBE1(x,y);
> ...
> 
> So that the line1 and line 2 don''t have to be implemented every
time
> even if the probe1 doesn''t be invoked?
> 
> Thanks for your information in advance!
> 
> 
> Jenny
--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

This is great! :-)


Thanks,
Jenny

Eric Schrock wrote On 03/31/06 11:56,:
> How convenient that Adam just fixed this bug yesterday:
> 
> 6405927 USDT is-enabled probes
> 
> This will give you exactly what you want.  It will be available in build
> 38.
> 
> - Eric
> 
> On Fri, Mar 31, 2006 at 11:39:03AM -0800, Luojia Chen wrote:
> 
>>Hi,
>>
>>If I have a DTrace probe defined with some parameters like:
>>	probe probe1(int, char)
>>
>>And when insert the probe somewhere into the application, it may need
>>call some functions/opteration to get the parameters for the probe, like
>>...
>>int x = XYZ + ABC; ---line1
>>char y = getY();   ---line2
>>PROVIDER_PROBE1(x,y);
>>...
>>
>>However,the problem here is: in order to insert the probe1 to the
>>application, we have to add line1,2 to get the parameters for the probe,
>>which can be a *big overhead* to the application.
>>
>>Is there some way to solve this problem? Something like:
>>
>>...
>>if(DTrace probe1 is invoked)
>>int x = XYZ + ABC; ---line1
>>char y = getY();   ---line2
>>PROVIDER_PROBE1(x,y);
>>...
>>
>>So that the line1 and line 2 don''t have to be implemented every
time
>>even if the probe1 doesn''t be invoked?
>>
>>Thanks for your information in advance!
>>
>>
>>Jenny
> 
> 
> --
> Eric Schrock, Solaris Kernel Development      
http://blogs.sun.com/eschrock
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

On Fri, 31 Mar 2006, Luojia Chen wrote:
> However,the problem here is: in order to insert the probe1 to the
> application, we have to add line1,2 to get the parameters for the probe,
> which can be a *big overhead* to the application.
>
> Is there some way to solve this problem? Something like:
>
> ...
> if(DTrace probe1 is invoked)
> int x = XYZ + ABC; ---line1
> char y = getY();   ---line2
> PROVIDER_PROBE1(x,y);
> ...
>
> So that the line1 and line 2 don''t have to be implemented every
time
> even if the probe1 doesn''t be invoked?
Hi Jenny,

I have been playing around with statically defined probes for the past 
few months, and have yet to find a way to do this ( the SDT chapter in the 
users guide doesn''t touch on this either). I know the DTrace team
members
get inundated with feature requests, but the ability to structure probes
with conditional logic would be super super useful. A perfect example of 
it''s use would be in retrieving data if a probe is enabled:

if (DTRACE_ENABLED) {

   /* apr_table_get will return the value of User-Agent or NULL */
   const char *userAgent = apr_table_get(r->headers_in,
"User-Agent");

   DTRACE_PROBE2(apache,
                 new__request,
                 r,
                 userAgent);
}

I am not sure how feasible it would be to add such a feature, or if this 
is on the DTrace roadmap, but this would be super super useful.

Hope team DTrace considers adding such a feature,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty

On Fri, 31 Mar 2006, Eric Schrock wrote:
> How convenient that Adam just fixed this bug yesterday:
>
> 6405927 USDT is-enabled probes
>
> This will give you exactly what you want.  It will be available in build
> 38.
Sweet! Thanks for adding this nifty feature!

Thanks,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty

> 
> On Fri, 31 Mar 2006, Luojia Chen wrote:
> 
> > However,the problem here is: in order to insert the probe1 to the
> > application, we have to add line1,2 to get the parameters for the
probe,
> > which can be a *big overhead* to the application.
> >
> > Is there some way to solve this problem? Something like:
> >
> > ...
> > if(DTrace probe1 is invoked)
> > int x = XYZ + ABC; ---line1
> > char y = getY();   ---line2
> > PROVIDER_PROBE1(x,y);
> > ...
> >
> > So that the line1 and line 2 don''t have to be implemented
every time
> > even if the probe1 doesn''t be invoked?
> 
> Hi Jenny,
> 
> I have been playing around with statically defined probes for the past 
> few months, and have yet to find a way to do this ( the SDT chapter in the 
> users guide doesn''t touch on this either). I know the DTrace team
members
> get inundated with feature requests, but the ability to structure probes
> with conditional logic would be super super useful. A perfect example of 
> it''s use would be in retrieving data if a probe is enabled:
> 
> if (DTRACE_ENABLED) {
> 
>    /* apr_table_get will return the value of User-Agent or NULL */
>    const char *userAgent = apr_table_get(r->headers_in,
"User-Agent");
> 
>    DTRACE_PROBE2(apache,
>                  new__request,
>                  r,
>                  userAgent);
> }
> 
> I am not sure how feasible it would be to add such a feature, or if this 
> is on the DTrace roadmap, but this would be super super useful.
> 
> Hope team DTrace considers adding such a feature,
> - Ryan
Good news: this feature just got integrated into Solaris Nevada by Adam
(he''s away on vacation now -- otherwise he would have announced it).
The
specific RFE is this one:

6405927 USDT is-enabled probes

and it''s actually much cooler than "DTRACE_ENABLED" because
it gives you
macros you can insert to ask if a given *probe* is enabled, giving you
very fine-grained control over such additional routines.  This will be
a huge help for instrumenting the Apaches, Pythons, Perls et al of the
world.  This will be in Solaris Express and OpenSolaris in the coming weeks.

-Mike

-- 
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/

On Fri, Mar 31, 2006 at 11:59:20AM -0800, Luojia Chen
wrote:
> This is great! :-)
Yeah, it''s awesome -- it''s one of those bits of technology
that is going to
allow lots of things that we didn''t anticipate.  For example, you can
use this technology to do fault injection with DTrace -- or more generally
to change the behavior of a running program in a way that has been
_designed_ into the program.  I don''t want to steal Adam''s
thunder by
sqwaking on too much about this, but this is a really cool bit of technology.
(Adam is currently away on vacation, but he''ll send out a complete
heads-up
mail once he returns late next week.)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

At the risk of having vegetables lobbed at me...
> Yeah, it''s awesome -- it''s one of those bits of
technology that is going to
> allow lots of things that we didn''t anticipate.  For example, you
can
> use this technology to do fault injection with DTrace -- or more generally
> to change the behavior of a running program in a way that has been
> _designed_ into the program.  I don''t want to steal
Adam''s thunder by
> sqwaking on too much about this, but this is a really cool bit of
technology.
> (Adam is currently away on vacation, but he''ll send out a complete
heads-up
> mail once he returns late next week.)
Forget six packs, I''d hijack a whole *beer truck* to have this
capability
in SDT in the kernel.

- Eric

Hi,

Thanks! However, one more question is:
In this case, it added the cost of one "if" statement,so is it meaning
that the cost will be much LOW(which is *great* improvement than without
this feature) but not Zero,Or is it somehow removed at all?


Jenny

Bryan Cantrill wrote On 03/31/06 12:51,:
> On Fri, Mar 31, 2006 at 11:59:20AM -0800, Luojia Chen wrote:
> 
>>This is great! :-)
> 
> 
> Yeah, it''s awesome -- it''s one of those bits of
technology that is going to
> allow lots of things that we didn''t anticipate.  For example, you
can
> use this technology to do fault injection with DTrace -- or more generally
> to change the behavior of a running program in a way that has been
> _designed_ into the program.  I don''t want to steal
Adam''s thunder by
> sqwaking on too much about this, but this is a really cool bit of
technology.
> (Adam is currently away on vacation, but he''ll send out a complete
heads-up
> mail once he returns late next week.)
> 
> 	- Bryan
> 
> --------------------------------------------------------------------------
> Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

> Thanks! However, one more question is:
> In this case, it added the cost of one "if" statement,so is it
meaning
> that the cost will be much LOW(which is *great* improvement than without
> this feature) but not Zero,Or is it somehow removed at all?
Oh, that''s the beauty. ;)  The cost is the cost of executing a nop,
thanks
to some tricks.  (Actually, as with USDT probes, the cost is not technically
zero -- because the compiler must treat it as a call site, the presence of
an is-enabled probe may induce some register pressure.  But you would be
really, really hard-pressed to observe this effect, and in many cases it
will have no effect whatsoever.)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

On Wed, Apr 05, 2006 at 01:42:02PM -0700, Bryan Cantrill
wrote:
> 
> > Thanks! However, one more question is:
> > In this case, it added the cost of one "if" statement,so is
it meaning
> > that the cost will be much LOW(which is *great* improvement than
without
> > this feature) but not Zero,Or is it somehow removed at all?
> 
> Oh, that''s the beauty. ;)  The cost is the cost of executing a
nop, thanks
> to some tricks.  
That should read "essentially the cost of executing a nop" -- there is
slightly more than a nop because it will be a move of a constant into a 
register (which is nearly always basically a nop), a register comparison 
instruction, and a branch, which should be not-taken.  (Programmers can
use #pragma rarely_executed in the is-enabled case to help the compiler
figure this out.)  So it''s a little more than a nop -- but the reason
that
I compare it to a nop is that it avoids memory operations.  With memory
operations being several orders of slower than CPU operations, this is 
the critical bit:  by avoiding memory operations, we are assured that the
disabled probe effect of is-enabled probes will be on the order of a single
digit number of nanoseconds, not the tens or hundreds (or even thousands) of
nanoseconds that is induced by a single load.

Anyway, suffice it to say that the disabled probe effect of is-enabled
probes is so small as to be unobservable...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

On Wed, 5 Apr 2006, Bryan Cantrill wrote:
> On Wed, Apr 05, 2006 at 01:42:02PM -0700, Bryan Cantrill wrote:
> >
> > > Thanks! However, one more question is:
> > > In this case, it added the cost of one "if"
statement,so is it meaning
> > > that the cost will be much LOW(which is *great* improvement than
without
> > > this feature) but not Zero,Or is it somehow removed at all?
> >
> > Oh, that''s the beauty. ;)  The cost is the cost of executing
a nop, thanks
> > to some tricks.
>
> That should read "essentially the cost of executing a nop" --
there is
> slightly more than a nop because it will be a move of a constant into a
> register (which is nearly always basically a nop), a register comparison
> instruction, and a branch, which should be not-taken.  (Programmers can
> use #pragma rarely_executed in the is-enabled case to help the compiler
> figure this out.)  So it''s a little more than a nop -- but the
reason that
> I compare it to a nop is that it avoids memory operations.  With memory
> operations being several orders of slower than CPU operations, this is
> the critical bit:  by avoiding memory operations, we are assured that the
> disabled probe effect of is-enabled probes will be on the order of a single
> digit number of nanoseconds, not the tens or hundreds (or even thousands)
of
> nanoseconds that is induced by a single load.
>
> Anyway, suffice it to say that the disabled probe effect of is-enabled
> probes is so small as to be unobservable...
Bryan - we are simply not worthy!  :)

Awesome.

Regards,

Al Hopper  Logical Approach Inc, Plano, TX.  al at logical-approach.com
           Voice: 972.379.2133 Fax: 972.379.2134  Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005

Hi, Bryan,

I''m reading your blog:
http://blogs.sun.com/roller/page/bmc/20060525

and wondering the question:
1. Do you have any update information on how''s the progress of DTrace
support on FreeBSD compared to Solaris 10''s DTrace?

2. Many of my ISVs are extremely interested in the cool DTrace feature
in Solaris 10, and I also got tons of questions from customers as: Will
there be any port plans to port DTrace to Linux?  Do you have any
information on this question? Personally, I think DTrace is very
critical for Solaris to finally win Linux for ISVs'' products, so I
guess
Sun wouldn''t put any effort to do/support the porting DTrace to Linux,
right? But I don''t quite understand why we support porting DTrace to
FreeBSD?

Thanks in advance for your comment and information!



Best Regards,
Jenny



Bryan Cantrill wrote On 04/05/06 14:00,:
> On Wed, Apr 05, 2006 at 01:42:02PM -0700, Bryan Cantrill wrote:
> 
>>>Thanks! However, one more question is:
>>>In this case, it added the cost of one "if" statement,so
is it meaning
>>>that the cost will be much LOW(which is *great* improvement than
without
>>>this feature) but not Zero,Or is it somehow removed at all?
>>
>>Oh, that''s the beauty. ;)  The cost is the cost of executing a
nop, thanks
>>to some tricks.  
> 
> 
> That should read "essentially the cost of executing a nop" --
there is
> slightly more than a nop because it will be a move of a constant into a 
> register (which is nearly always basically a nop), a register comparison 
> instruction, and a branch, which should be not-taken.  (Programmers can
> use #pragma rarely_executed in the is-enabled case to help the compiler
> figure this out.)  So it''s a little more than a nop -- but the
reason that
> I compare it to a nop is that it avoids memory operations.  With memory
> operations being several orders of slower than CPU operations, this is 
> the critical bit:  by avoiding memory operations, we are assured that the
> disabled probe effect of is-enabled probes will be on the order of a single
> digit number of nanoseconds, not the tens or hundreds (or even thousands)
of
> nanoseconds that is induced by a single load.
> 
> Anyway, suffice it to say that the disabled probe effect of is-enabled
> probes is so small as to be unobservable...
> 
> 	- Bryan
> 
> --------------------------------------------------------------------------
> Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc
-- 

   Jenny Chen
   Software Engineer
   Market Development Engineering
   v-mail:(510) 574-7149
   SUN Microsystems

> I''m reading your blog:
> http://blogs.sun.com/roller/page/bmc/20060525
> 
> and wondering the question:
> 1. Do you have any update information on how''s the progress of
DTrace
> support on FreeBSD compared to Solaris 10''s DTrace?
The FreeBSD folks are making great progress, and -- as I mentioned --
DTrace as it stands today is (or should be) quite useful in terms of
FreeBSD development.  

In terms of the differences, the FreeBSD port (currently) lacks a couple
of huge features:

  - The ability to instrument user-level
  - User-level SDT probes (so no Java/Perl/Python/Ruby instrumentation)
  - The stack()/ustack()/jstack() actions
  - The stable in-kernel providers (io, proc, sched, lockstat, etc.), 

More details are here:

  http://people.freebsd.org/~jb/dtrace/todo.html
> 2. Many of my ISVs are extremely interested in the cool DTrace feature
> in Solaris 10, and I also got tons of questions from customers as: Will
> there be any port plans to port DTrace to Linux?  Do you have any
> information on this question? Personally, I think DTrace is very
> critical for Solaris to finally win Linux for ISVs'' products, so I
guess
> Sun wouldn''t put any effort to do/support the porting DTrace to
Linux,
> right? 
You have to ask that question to the Linux folks.  The Linux community has
shown absolutely no interest in DTrace, so I would say that it''s
unlikely.
Yes, there are some lincensing issues, but as I wrote on OSNews earlier
this year, I can''t imagine that these issues are insurmountable:

    I am not a lawyer (and this is not legal advice) but as far as CDDL is
    concerned, you can drop DTrace into anything. (Yes, Microsoft could
    drop DTrace into Windows or IBM could drop it into AIX -- were either
    so inclined.) The issue around Linux is the GPL, not the CDDL: one
    would have to consult the FSF as to the interoperability of CDDL with
    the GPL, and Linus as to the Linux definition of the Program.
    Historically, the FSF has said that CDDL and GPL don''t mix -- but
    Torvalds has been very murky on his definition of the Program. (In
    particular, the legal status of so-called "Tainted kernels" has
never
    been tested.) If the definition were firmed up to limit the definition
    of the Program to those components explicitly licensed under the GPL
    (i.e. a file-based approach), then one could presumably drop DTrace
    into Linux without violating the GPL. I think if the Linux folks
    wanted DTrace enough -- and certainly if Linus wanted it -- they could
    find a way to legally do it. That said, I don''t think
there''s much
    interest in DTrace among the influential Linux folks...
> But I don''t quite understand why we support porting DTrace to
FreeBSD?
Because it enlarges the DTrace community.  This is the right Sun business
decision for the same reason that OpenSolaris is the right Sun business
decision:  it doesn''t drive any away existing revenue, it costs us
nothing,
(or next-to-nothing in OpenSolaris'' case) and it has positive secondary
and tertiary effects on our revenue.  To make this more concrete, thanks
in large part to the efforts around the FreeBSD port, DTrace was recently
featured on Geek Muse:

  http://blogs.sun.com/roller/page/ahl?entry=dtrace_on_geek_muse

Geek Muse was wildly positive about DTrace -- and now they''re
interested
in having Adam on the show to talk more about it.  This kind of excitement
and interest wouldn''t have happened without the FreeBSD port, and
it''s
pretty clear that someone who''s psyched about DTrace will think of Sun
differently when''s time to buy a new server or evaluate a new operating
system or whatever.

As I wrote in my blog, the FreeBSD port of DTrace is a win for everyone:
it''s a win for DTrace users, it''s a win for Sun, and
it''s a big, big win
for FreeBSD users.

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

> As I wrote in my blog, the FreeBSD port of DTrace is a win for everyone:
> it''s a win for DTrace users, it''s a win for Sun, and
it''s a big, big win
> for FreeBSD users.
Note also that the FreeBSD community has been reciprocally supportive of 
OpenSolaris -- many device drivers have been and are being ported from 
FreeBSD to Solaris. The FreeBSD community has perpetually embraced the 
spirit of open software, and the OpenSolaris community is too.

It''s not about "us versus them" but instead how we can help
each other
produce better operating systems.

- Eric

> 1. Do you have any update information on how''s the progress of
DTrace
> support on FreeBSD compared to Solaris 10''s DTrace?
I''ve been trying out the DTrace on FreeBSD. It looks to be very stable 
and works fine for me !

Many DTrace features including aggregation and quantization are already 
there. The providers implemented so far are dtrace, systrace, fbt and 
profile. It gives me around 3100+ probes on my system. Would love to see 
the pid provider coming soon.

It is fantastic to see that two operating systems with a great history 
are working together !

Cheers,
Ananth

Adam,

My ISV(MySQL) is working on implementing more DTrace probes into their code, and
I had sent them the  instructions on your website:

http://www.opensolaris.org/jive/thread.jspa?messageID=23815&+23815)

However, their Sol 10 build was obviously before 34, so that "dtrace
-h" was not surported. Is there any patch for these USDT enhancements  on
your website that I can point to them?

Thanks in advance for your information!


Jenny

   Jenny Chen              
   Software Engineer                 
   Market Development Engineering      
   v-mail:(650) 786-4477                                  
   SUN Microsystems

----- Original Message -----
From: Luojia Chen <luojia.chen at sun.com>
Date: Thursday, March 9, 2006 3:39 pm
Subject: Re: [dtrace-discuss] question about compile application with DTrace
probes
To: Adam Leventhal <ahl at eng.sun.com>
Cc: Jonathan Adams <Jonathan.Adams at Sun.COM>,  dtrace-discuss at
opensolaris.org
> Yes, it works!
> 
> 
> Thanks!
> Jenny
> 
> 
> 
> 
> Adam Leventhal wrote On 03/09/06 13:19,:
> > Right. Since you''re using C++ you need to follow the new 
> directions in the
> > post I mentioned:
> > 
> >     
> http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815> 
> > Adam
> > 
> > On Thu, Mar 09, 2006 at 12:12:00PM -0800, Luojia Chen wrote:
> > 
> >>Adm,
> >>
> >>Adam Leventhal wrote On 03/09/06 11:10,:
> >>
> >>>Hi Jenny,
> >>>
> >>>Thanks for sending the output I asked for.
> >>>
> >>>The problem you''re seeing is related to C++ symbol
name mangling
> (the example
> >>>you gave would more accurately have been ''gcc -c
src1.cc'' not
> ''cc -c src1.c''
> >>>-- a fairly significant difference). gcc was renaming your 
> symbol from
> >>>__dtrace_appprobe___probe1 to _Z35__dtrace_appprobe___probe1; 
> dtrace -G
> >>>therefore wasn''t identifying it which caused the
linker to fail.
> >>
> >>I just tried with our venus compiler, but the 
> __dtrace_appprobe___probe1>>was changed to be 
> __1cbJ__dtrace_appprobe___probe1 in my case, causing
> >>the same failure?
> >>
> >>
> >>Thanks,
> >>Jenny
> >>
> >>
> >>
> >>>Take a look at my post to the discussion forum on how to use
the
> new USDT
> >>>headergen feature to embed probes:
> >>>
> >>>  
>
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815>>>
> >>>You should also make sure you''re using the Solaris
linker and
> not the gnu
> >>>linker. There are some modifications we made to support USDT 
> which haven''t
> >>>been implemented yet in the gnu linker.
> >>>
> >>>Adam
> >>>
> >>>On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal wrote:
> >>>
> >>>
> >>>>Hi Jenny,
> >>>>
> >>>>Running dtrace -G on src1.o should have removed any
references
> to symbols
> >>>>starting with __dtrace. Can you send me the output of
''elfdump -
> s src1.o''
> >>>>before and after you run it through dtrace -G?
> >>>>
> >>>>Can you also send the output of ''ld -V''?
> >>>>
> >>>>Thanks.
> >>>>
> >>>>Adam
> >>>>
> >>>>On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen
wrote:
> >>>>
> >>>>
> >>>>>Hi,
> >>>>>
> >>>>>In the last step, I have all the other undefined
symbols
> solved, but
> >>>>>just the "__dtrace_appprobe___probe1()" left.
> >>>>>
> >>>>>This is version: Solaris Nevada snv_34 SPARC, any 
> comment/feedback on
> >>>>>this problem?
> >>>>>
> >>>>>
> >>>>>Thanks!
> >>>>>Jenny
> >>>>>
> >>>>>Luojia Chen wrote On 03/08/06 15:28,:
> >>>>>
> >>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>The steps & output were as bellow:
> >>>>>>
> >>>>>>Jonathan Adams wrote On 03/08/06 14:43,:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>On Wed, Mar 08, 2006 at 02:32:40PM -0800,
Luojia Chen wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Hi,
> >>>>>>>>
> >>>>>>>>I''m trying to insert some DTrace
probes into the
> application by
> >>>>>>>>following the steps as:
> >>>>>>>>
> >>>>>>>>1. compiled "appprobe.d"
including the provider/probes
> definition by runing
> >>>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> >>>>>>>>(src1.c is the source code added with the
DTrace probes,
> ans src2 are
> >>>>>>>>have the functions/variables
implementation/definitions
> that src1.c need
> >>>>>>>>to call from.
> >>>>>>>>
> >>>>>>>>2. cc -o test appprobe.d src1.o src2.o
> >>>>>>>
> >>>>>>>              ^^^^^^^^^^ appprobe.o?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>---- Here I got error as bellow and the
compilation failed:
> >>>>>>>>  Undefined symbol:
__dtrace_appprobe___probe1()(first
> referenced in
> >>>>>>>>file src1.o)
> >>>>>>>>
> >>>>>>>>Any comment on why the compilation failed?
> >>>>>>>>Thanks in advance for your information, and
could you
> please send to my
> >>>>>>>>email directly since I''m not
currently in this email alias.
> >>>>>>>
> >>>>>>>
> >>>>>>>It looks like src1.o didn''t get
properly munged by dtrace;
> could you
> >>>>>>>give the full sequence of steps, with all of
the output?
> >>>>>>>
> >>>>>>>The steps should be something like:
> >>>>>>>
> >>>>>>>cc -c src1.c
> >>>>>>>cc -c src2.c
> >>>>>>
> >>>>>>
> >>>>>>The two steps generated src1.o, src2.o
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> >>>>>>
> >>>>>>
> >>>>>>This step generated appprobe.o
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>cc -o test approbe.o src1.o src2.o
> >>>>>>
> >>>>>>
> >>>>>>--> errors generated here:
> >>>>>>
> >>>>>>Undefined                       first referenced
> >>>>>>symbol                             in file
> >>>>>>cos                                 item_func.o
> >>>>>>exp                                 item_func.o
> >>>>>>log                                 item_func.o
> >>>>>>...
> >>>>>>__dtrace_appprobe___probe1()            src1.o
> >>>>>>...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Thanks!
> >>>>>>Jenny
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Cheers,
> >>>>>>>- jonathan
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>-- 
> >>>>>
> >>>>>  Jenny Chen
> >>>>>  Software Engineer
> >>>>>  Market Development Engineering
> >>>>>  v-mail:(510) 574-7149
> >>>>>  SUN Microsystems
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>dtrace-discuss mailing list
> >>>>>dtrace-discuss at opensolaris.org
> >>>>
> >>>>-- 
> >>>>Adam Leventhal, Solaris Kernel Development       
>
http://blogs.sun.com/ahl>>>>_______________________________________________
> >>>>dtrace-discuss mailing list
> >>>>dtrace-discuss at opensolaris.org
> >>>
> >>>
> >>-- 
> >>
> >>   Jenny Chen
> >>   Software Engineer
> >>   Market Development Engineering
> >>   v-mail:(510) 574-7149
> >>   SUN Microsystems
> >>
> >>
> > 
> > 
> 
> -- 
> 
>   Jenny Chen
>   Software Engineer
>   Market Development Engineering
>   v-mail:(510) 574-7149
>   SUN Microsystems
> 
> 
> 
>

Hi Jenny,

There''s no patch yet, but we''re expecting one at some point.

Adam

On Wed, Sep 20, 2006 at 05:29:12PM -0700, Luojia Chen
wrote:
> Adam,
> 
> My ISV(MySQL) is working on implementing more DTrace probes into their
code, and I had sent them the  instructions on your website:
> 
> http://www.opensolaris.org/jive/thread.jspa?messageID=23815&+23815)
> 
> However, their Sol 10 build was obviously before 34, so that "dtrace
-h" was not surported. Is there any patch for these USDT enhancements  on
your website that I can point to them?
> 
> Thanks in advance for your information!
> 
> 
> Jenny
> 
>    Jenny Chen              
>    Software Engineer                 
>    Market Development Engineering      
>    v-mail:(650) 786-4477                                  
>    SUN Microsystems
> 
> ----- Original Message -----
> From: Luojia Chen <luojia.chen at sun.com>
> Date: Thursday, March 9, 2006 3:39 pm
> Subject: Re: [dtrace-discuss] question about compile application with
DTrace probes
> To: Adam Leventhal <ahl at eng.sun.com>
> Cc: Jonathan Adams <Jonathan.Adams at Sun.COM>,  dtrace-discuss at
opensolaris.org
> 
> > Yes, it works!
> > 
> > 
> > Thanks!
> > Jenny
> > 
> > 
> > 
> > 
> > Adam Leventhal wrote On 03/09/06 13:19,:
> > > Right. Since you''re using C++ you need to follow the new
> > directions in the
> > > post I mentioned:
> > > 
> > >     
> >
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815>
> > > Adam
> > > 
> > > On Thu, Mar 09, 2006 at 12:12:00PM -0800, Luojia Chen wrote:
> > > 
> > >>Adm,
> > >>
> > >>Adam Leventhal wrote On 03/09/06 11:10,:
> > >>
> > >>>Hi Jenny,
> > >>>
> > >>>Thanks for sending the output I asked for.
> > >>>
> > >>>The problem you''re seeing is related to C++
symbol name mangling
> > (the example
> > >>>you gave would more accurately have been ''gcc -c
src1.cc'' not
> > ''cc -c src1.c''
> > >>>-- a fairly significant difference). gcc was renaming your
> > symbol from
> > >>>__dtrace_appprobe___probe1 to
_Z35__dtrace_appprobe___probe1;
> > dtrace -G
> > >>>therefore wasn''t identifying it which caused the
linker to fail.
> > >>
> > >>I just tried with our venus compiler, but the 
> > __dtrace_appprobe___probe1>>was changed to be 
> > __1cbJ__dtrace_appprobe___probe1 in my case, causing
> > >>the same failure?
> > >>
> > >>
> > >>Thanks,
> > >>Jenny
> > >>
> > >>
> > >>
> > >>>Take a look at my post to the discussion forum on how to
use the
> > new USDT
> > >>>headergen feature to embed probes:
> > >>>
> > >>>  
> >
http://www.opensolaris.org/jive/thread.jspa?messageID=23815&#23815>>>
> > >>>You should also make sure you''re using the
Solaris linker and
> > not the gnu
> > >>>linker. There are some modifications we made to support
USDT
> > which haven''t
> > >>>been implemented yet in the gnu linker.
> > >>>
> > >>>Adam
> > >>>
> > >>>On Thu, Mar 09, 2006 at 10:11:12AM -0800, Adam Leventhal
wrote:
> > >>>
> > >>>
> > >>>>Hi Jenny,
> > >>>>
> > >>>>Running dtrace -G on src1.o should have removed any
references
> > to symbols
> > >>>>starting with __dtrace. Can you send me the output of
''elfdump -
> > s src1.o''
> > >>>>before and after you run it through dtrace -G?
> > >>>>
> > >>>>Can you also send the output of ''ld
-V''?
> > >>>>
> > >>>>Thanks.
> > >>>>
> > >>>>Adam
> > >>>>
> > >>>>On Wed, Mar 08, 2006 at 05:31:56PM -0800, Luojia Chen
wrote:
> > >>>>
> > >>>>
> > >>>>>Hi,
> > >>>>>
> > >>>>>In the last step, I have all the other undefined
symbols
> > solved, but
> > >>>>>just the "__dtrace_appprobe___probe1()"
left.
> > >>>>>
> > >>>>>This is version: Solaris Nevada snv_34 SPARC, any 
> > comment/feedback on
> > >>>>>this problem?
> > >>>>>
> > >>>>>
> > >>>>>Thanks!
> > >>>>>Jenny
> > >>>>>
> > >>>>>Luojia Chen wrote On 03/08/06 15:28,:
> > >>>>>
> > >>>>>
> > >>>>>>Hi,
> > >>>>>>
> > >>>>>>The steps & output were as bellow:
> > >>>>>>
> > >>>>>>Jonathan Adams wrote On 03/08/06 14:43,:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>On Wed, Mar 08, 2006 at 02:32:40PM -0800,
Luojia Chen wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>Hi,
> > >>>>>>>>
> > >>>>>>>>I''m trying to insert some
DTrace probes into the
> > application by
> > >>>>>>>>following the steps as:
> > >>>>>>>>
> > >>>>>>>>1. compiled "appprobe.d"
including the provider/probes
> > definition by runing
> > >>>>>>>>dtrace -G -32 -s appprobe.d src1.o
src2.o
> > >>>>>>>>(src1.c is the source code added with
the DTrace probes,
> > ans src2 are
> > >>>>>>>>have the functions/variables
implementation/definitions
> > that src1.c need
> > >>>>>>>>to call from.
> > >>>>>>>>
> > >>>>>>>>2. cc -o test appprobe.d src1.o src2.o
> > >>>>>>>
> > >>>>>>>              ^^^^^^^^^^ appprobe.o?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>>---- Here I got error as bellow and
the compilation failed:
> > >>>>>>>>  Undefined symbol:
__dtrace_appprobe___probe1()(first
> > referenced in
> > >>>>>>>>file src1.o)
> > >>>>>>>>
> > >>>>>>>>Any comment on why the compilation
failed?
> > >>>>>>>>Thanks in advance for your
information, and could you
> > please send to my
> > >>>>>>>>email directly since I''m not
currently in this email alias.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>It looks like src1.o didn''t get
properly munged by dtrace;
> > could you
> > >>>>>>>give the full sequence of steps, with all
of the output?
> > >>>>>>>
> > >>>>>>>The steps should be something like:
> > >>>>>>>
> > >>>>>>>cc -c src1.c
> > >>>>>>>cc -c src2.c
> > >>>>>>
> > >>>>>>
> > >>>>>>The two steps generated src1.o, src2.o
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>dtrace -G -32 -s appprobe.d src1.o src2.o
> > >>>>>>
> > >>>>>>
> > >>>>>>This step generated appprobe.o
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>cc -o test approbe.o src1.o src2.o
> > >>>>>>
> > >>>>>>
> > >>>>>>--> errors generated here:
> > >>>>>>
> > >>>>>>Undefined                       first
referenced
> > >>>>>>symbol                             in file
> > >>>>>>cos                                
item_func.o
> > >>>>>>exp                                
item_func.o
> > >>>>>>log                                
item_func.o
> > >>>>>>...
> > >>>>>>__dtrace_appprobe___probe1()            src1.o
> > >>>>>>...
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>Thanks!
> > >>>>>>Jenny
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>>Cheers,
> > >>>>>>>- jonathan
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>-- 
> > >>>>>
> > >>>>>  Jenny Chen
> > >>>>>  Software Engineer
> > >>>>>  Market Development Engineering
> > >>>>>  v-mail:(510) 574-7149
> > >>>>>  SUN Microsystems
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>_______________________________________________
> > >>>>>dtrace-discuss mailing list
> > >>>>>dtrace-discuss at opensolaris.org
> > >>>>
> > >>>>-- 
> > >>>>Adam Leventhal, Solaris Kernel Development       
> >
http://blogs.sun.com/ahl>>>>_______________________________________________
> > >>>>dtrace-discuss mailing list
> > >>>>dtrace-discuss at opensolaris.org
> > >>>
> > >>>
> > >>-- 
> > >>
> > >>   Jenny Chen
> > >>   Software Engineer
> > >>   Market Development Engineering
> > >>   v-mail:(510) 574-7149
> > >>   SUN Microsystems
> > >>
> > >>
> > > 
> > > 
> > 
> > -- 
> > 
> >   Jenny Chen
> >   Software Engineer
> >   Market Development Engineering
> >   v-mail:(510) 574-7149
> >   SUN Microsystems
> > 
> > 
> > 
> > 
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl