This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gprof and LinuxThreads


Geoff Keating <geoffk@ozemail.com.au> writes:

> > 1- Each thread needs to do "moncontrol(1);" at start-up in order
> >    to activate PC sampling for that thread.  This could easily be done
> >    in a profiling version of libpthread (libpthread_p.a ?)
> 
> Better, surely, to do it in the usual libpthread library, because that
> way people don't have to have huge binaries just to profile their
> executables.

Geoff is also right, it also has to happen in the normal library.  We
have to take care of the __gmon_start__ function not only in the
normal startup code, but also when starting threads.

> It's not unlikely that on a fast machine, all the sampling will happen
> at the same time; all that would be required is for all threads to
> start inside the same tick.  This could produce wrong results if the
> code spends much time inside some small inner loop (as code tends to
> do).

Before be think about fixing the broken implementation let's make a
step back and look at the ugly and limited design.  I would rather
like to replace the whole implementation.

Did you ever tried to profile a program which didn't ran for minutes?
On my home machine I see for these programs zero hits for almost all
the functions, rendering the data useless.  Even with an increase of
the itimer frequency this will not be fixed (maybe alpha 1kHz timers
are a bit better but I doubt the results are that useful).

I'm not sure how to solve the problem.  Maybe with some kernel help,
maybe with ptrace from another process, I haven't thought enough about
it in the moment.

All I can say is that the current implementation is not worth spending
much time.  If we can fix a few problems easily, fine.

> Should the libc be exporting <atomicity.h>?  It seems like the sort of
> thing that user programs might find useful...

I don't want to have yet another interface exported.  Especially one
where the interface might change.  We should have an extra package
with functionality like this.  I have a small collection of libraries
for performance measurement and things like this, maybe combining all
of them is the correct answer.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]