dtrace discuss - Jul 2006 - Question about the dtrace -G command...

Hi.

I have been reading: http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view
but I feel that I am missing some details to fully understand the build / link
process...
>From the web-page:
"The dtrace command shown above post-processes the object files generated
by the preceding compiler commands and generates the object file myserv.o from
myserv.d and the other object files. The dtrace -G option is used to link
provider and probe definitions with a user application. "

So what does this really mean? If I have a large project containing multiple ar
archives used in multiple programs, how should I implement my build environment.
Do I need to extract each object file from the ar archive before the link step
and "post-process" all of the object files, or may I insert
"post-processed" object files (and the object file created by dtrace)
into the ar archive. I guess that I whould like to know the details of the
dtrace command ;-)

Any comment would be appreciated

Trond
 
 
This message posted from opensolaris.org

Hi Trond,

Here''s an example of how to use USDT that might help:

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

In general, you have to ''dtrace -G'' must be handed all object
files that
contain DTrace probe sites. For your specific example, if you have objects
in multiple archives with probes, yes, you''ll need to extract the
object
files from the archives (dtrace(1M) can''t handle archives, but that
might
be a reasonable RFE). If the object files for a particular USDT provider
are all within the same archive, I''d suggest building the provider
object
and including that in the archive.

Hope that helps.

Adam

On Tue, Jul 25, 2006 at 12:45:50AM -0700, Trond Norbye
wrote:
> Hi.
> 
> I have been reading:
http://docs.sun.com/app/docs/doc/817-6223/6mlkidlms?a=view but I feel that I am
missing some details to fully understand the build / link process...
> 
> >From the web-page:
> 
> "The dtrace command shown above post-processes the object files
generated by the preceding compiler commands and generates the object file
myserv.o from myserv.d and the other object files. The dtrace -G option is used
to link provider and probe definitions with a user application. "
> 
> So what does this really mean? If I have a large project containing
multiple ar archives used in multiple programs, how should I implement my build
environment. Do I need to extract each object file from the ar archive before
the link step and "post-process" all of the object files, or may I
insert "post-processed" object files (and the object file created by
dtrace) into the ar archive. I guess that I whould like to know the details of
the dtrace command ;-)
> 
> Any comment would be appreciated
> 
> Trond
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

> Hi Trond,
> 
> Here''s an example of how to use USDT that might help:
> 
> http://blogs.sun.com/roller/page/ahl?entry=user_land_tracing_gets_better
> 
> In general, you have to ''dtrace -G'' must be handed all
object files that
> contain DTrace probe sites. For your specific example, if you have objects
> in multiple archives with probes, yes, you''ll need to extract the
object
> files from the archives (dtrace(1M) can''t handle archives, but
that might
> be a reasonable RFE). If the object files for a particular USDT provider
> are all within the same archive, I''d suggest building the provider
object
> and including that in the archive.
> 
> Hope that helps
> 
I almost get it now, but I''ll just ask some additional questions just
to be on the safe side.

I must add _all_ of the object files implementing probes for a given provider at
the same invocation of dtrace -G? (if I implement some of the probes in another
library, I cannot perform a separate dtrace -G command there and add the two
objects to another archive?..)

Since I''m just starting to add probes to the application, I need to
figure out how to integrate this additional link-step into the build process. I
would relly like to avoid to edit all of the makefiles. Any good ideas?

Trond
 
 
This message posted from opensolaris.org

On Tue, Jul 25, 2006 at 12:57:34PM -0700, Trond Norbye
wrote:
> I must add _all_ of the object files implementing probes for a given
> provider at the same invocation of dtrace -G? (if I implement some of
> the probes in another library, I cannot perform a separate dtrace -G
> command there and add the two objects to another archive?..)
That''s right. dtrace -G records information about those object files in
the object file it produces and that can''t (at present) be done
incrementally.
> Since I''m just starting to add probes to the application, I need
to
> figure out how to integrate this additional link-step into the build
> process. I would relly like to avoid to edit all of the makefiles. Any
> good ideas?
It''s hard to give a good suggestion without knowing the details of how
the
Makefiles already work.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

> On Tue, Jul 25, 2006 at 12:57:34PM -0700, Trond
> Norbye wrote:
> > I must add _all_ of the object files implementing probes for a given
> > provider at the same invocation of dtrace -G? (if I implement some of
> > the probes in another library, I cannot perform a separate dtrace -G
> > command there and add the two objects to another archive?..)
> 
> That''s right. dtrace -G records information about those object
files in
> the object file it produces and that can''t (at present) be done
incrementally.
> 
Thank you very much for that clarification.
> > Since I''m just starting to add probes to the application, I
need to
> > figure out how to integrate this additional link-step into the build
> > process. I would relly like to avoid to edit all of the makefiles. Any
> > good ideas?
> 
> It''s hard to give a good suggestion without knowing the details of
how the
> Makefiles already work.
To be completely honest, I have not figured that completely out yet but
I''m working on it ;-)

My current plan now is to replace the "compiler" invoked on the link
step with my own little script. The plan was to let the script first extract all
of the object files contained inside all archives and then pass all of them
together with my dtrace provider-definition to dtrace. Then the plan was to put
the the object files back into new archives, and then invoke the real compiler
with the "original" argument (except that I point to the new archives
and the new object file created by dtrace)...

This problably sound like a "lot of extra work", but I probably think
it''s the easiest soultion (in the long run) since I use the same
makefiles for multiple platforms (but I use different macros on the various
targets). Otherwise I need specialized macros each time I add a new provider to
a new source file.

Anyway, thank you very much for your comments! I now feel comfortable about the
linking details, and I only have the "how to implement it" to worry
about ;-)

Trond
 
 
This message posted from opensolaris.org