svn commit: r228143 - in head: . share/mk tools/build/options

[Steve Kargl]

On Mon, Dec 19, 2011 at 05:04:43PM -0600, Brooks Davis wrote:
> On Mon, Dec 19, 2011 at 12:41:29PM -0800, Steve Kargl wrote:
> > On Mon, Dec 19, 2011 at 08:09:32PM +0000, David Chisnall wrote:
> > > On 19 Dec 2011, at 19:52, Warner Losh wrote:
> > > 
> > > > -1.  The needs of the many?  Please.  Let's break a useful feature because some people don't understand it and are impatient?  That's lame.
> > > 
> > > How useful is gprof-based profiling these days?  Now that we
> > > have the DTrace pid provider, don't we have access to much more
> > > fine-grained profiling information without the need for shipping
> > > two versions of every library?
> > 
> > It is quite uesful given that for the last 20 or so years,
> > I can do 
> > 
> > cc -o z -pg a.c -lm_p
> >  ./z
> > gprof -b -l ./z z.gmon | more
> > 
> >   %   cumulative   self              self     total           
> >  time   seconds   seconds    calls  ms/call  ms/call  name    
> >  72.1       0.91     0.91        0  100.00%           _mcount [1]
> >  11.1       1.05     0.14  8388608     0.00     0.00  sinf [4]
> >   8.2       1.16     0.10  8388608     0.00     0.00  nextafterf [5]
> >   4.6       1.21     0.06        0  100.00%           .mcount (9)
> > 
> > to ge the information I want.
> 
> I'd tend to agree that we should leave it on at least in HEAD.

I think it should be the default on all branches.  It adds about
28 MB to /usr/lib and 10 minutes to buildworld on my x86_64 systems,
ie., it is in the noise.

> > dtrace(1M) does not seem to contain an example that gives the
> > equivalent information.  In fact, the manpage contains no examples,
> > only the statement:
> > 
> >   See the Solaris Dynamic Tracing Guide for detailed examples
> >   of how to use the dtrace utility to perform these tasks.
> > 
> > which, of course, is not very useful given that I do not have a
> > Solaris Dynamic Tracing Guide.
> 
> http://docs.oracle.com/cd/E19253-01/817-6223/ is it and the first hit in
> google...
> 

Which isn't very useful if the system that I'm working on
has no or very limit internet access. 

A quick scan of Ch. 19, 'profile Provider' does not give
anything that looks remotely similar to the above 3 command
lines.  Ch. 33 'User Process Tracing' isn't any better.  
Telling a users that getting an execution profile for her
code can be done by first learning the D programming language
and then reading a 41 Chapter document available on the
web isn't too user friendly.  And, if I read Chapter 26 of
the FreeBSD Handbook correctly:
1) dtrace is experimental
2) one needs to build a kernel with the KDTRACE_HOOKS, DDB_CTF,
   and possibly KDTRACE_FRAME.
3) one needs to 'kldload dtraceall' module, which is a showstopper
   for anyone who builds his kernel with 'makeoptions NO_MODULES'

-- 
Steve