2 problems with sprof

[Owen Taylor]

Jakub Jelinek <jakub@redhat.com> writes:

> On Sun, Sep 23, 2001 at 09:22:32AM -0700, H . J . Lu wrote:
> > > [I personally don't feel the urge to do this right now since we still
> > > have no high-resolution timers.  Without them any new profiling code
> > > is rather meaningless.]
> > 
> > Can we change HZ in kernel to get high-resolution timer?
> 
> IMHO it would be far better to teach gcc to emit _mcount style profiling
> hooks both in function prologue and function epilogue. Then you don't have
> to worry about timer sampling and instead do rdtsc during entering of each
> function and rdtsc when leaving that function. On most arches this would
> still without proper kernel support give you strange values when process was
> rescheduled (but e.g. on SPARC you can choose userland tick timers), but
> even that will be far more accurate than using SIGPROF based sampling.

The oprof kernel-based profiler takes a slightly different approach
and arranges to record data every N increments of a performance
monitoring counter. It records the data to a separate daemon currently
but could conceivably send a signal to the profiled process instead.

This doesn't give you the infinite-granularity of recording the
performance-monitoring counters in -finstrument-functions but
may be a little more manageable within current tools.

Regards,
                                        Owen

[ What profiling on Linux really needs is not more 10% better hacks
  but for someone to have the time to create a nice coherent 
  useable-by-non-uebergeeks framework that just _works_. ]