lkml.org 
[lkml]   [2002]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: libc/1427: gprof does not profile threads <synopsis of the problem (one li\ne)>
Jakub Jelinek wrote:
>
> On Wed, Mar 13, 2002 at 04:19:02PM -0800, Dan Kegel wrote:
> > Ulrich Drepper wrote:
> > >
> > > On Wed, 2002-03-13 at 15:17, Dan Kegel wrote:
> > >
> > > > So let's break the logjam and fix glibc's linuxthreads' pthread_create
> > > > to [support profiling multithreaded programs]
> > >
> > > I will add nothing like this. The implementation is broken enough and
> > > any addition just makes it worse. If you patch your own code you'll get
> > > what you want at your own risk.
> >
> > OK. What's the right way to fix this, then?
>
> Surely don't use timer for profiling.
> Have the compiler generate profiling calls both at function entry and exit
> and use rdtsc/whatever other register your machine has (or even better
> profiling registers) to note time of that function being entered/left.

That's a different style of profiling. There is a fellow
working on that (see http://sourceforge.net/projects/fnccheck )
but there's value in the gprof-style of profiling as well.
(For instance, I suspect it's lower overhead.)

I think it's reasonable for us to get gprof working; it's
a useful part of classic Unix, and the fix looks easy.

Ulrich, do you at least agree that it would be desirable for
gprof to work properly on multithreaded programs?

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.123 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site