Re: libc/1427: gprof does not profile threads <synopsis of the problem

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Dan Kegel]

Alan Cox wrote:
> Dan Kegel wrote:
> > I'm all in favor of a userspace fix.  I suggested a patch
> > to glibc to fix this.  Ulrich rejected it; I'm trying
> > to coax out of him how he thinks profiling of multithreaded
> > programs on Linux should be fixed.
> 
> Good and I'll reject any kernel patches 8)
> 
> If Ulrich won't talk then talk to the NGPT people. Maybe a little
> competition will warm things up.

Surely Ulrich will come up with a constructive proposal for
how to make gprof work with LinuxThreads.  He wouldn't
want an important tool like gprof to remain broken for
years, would he?

While I await his constructive response, perhaps I'll get my 
glibc patch in shape.
I am maintainer of what amounts to a tiny embedded linux
distribution, and I'm pretty sure my users would like
gprof to work.  (In fact, my boss's boss would really
like gprof to work.  This problem has a lot of visibility.)

- Dan

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[jlnance]

On Wed, Mar 13, 2002 at 08:25:21PM -0800, Dan Kegel wrote:

> While I await his constructive response, perhaps I'll get my 
> glibc patch in shape.
> I am maintainer of what amounts to a tiny embedded linux
> distribution, and I'm pretty sure my users would like
> gprof to work.  (In fact, my boss's boss would really
> like gprof to work.  This problem has a lot of visibility.)

Does gprof work with dynamically loaded libraries?  I remember trying to
get it to work with mozilla and if I remember correctly it would not
work because mozilla used threads and it dlopen()ed things.

Thanks,

Jim

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Alan Cox]

> distribution, and I'm pretty sure my users would like
> gprof to work.  (In fact, my boss's boss would really
> like gprof to work.  This problem has a lot of visibility.)

So would lots of people. You might find the gprof maintainr would like to
ship your patch with his package for example 8)

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Dan Kegel]

Dave McCracken <dmccr@us.ibm.com> wrote:
> > It even looks like kernel support is included 2.4.19-pre3:
> > 
> > http://oss.software.ibm.com/pthreads/
> > 
> > But don't see anything about it in any of the recent change logs...
> 
> The relevant line from the changelog is:
> 
> - Signal changes for thread groups                      (Dave McCracken)
> 
> This is the only patch that NGPT needs to work.

Does NGPT support profiling yet?  i.e. can I compile a program
using -pg and NGPT, and view the runtime distribution histogram
with gprof?

- Dan

Re: libc/1427: gprof does not profile threads <synopsis of the problem (one li\ne)>

[Dan Kegel]

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?

Here are a few alternate ideas off the top of my head:

* Rip out Linuxthreads, replace it with NGPT, and
start fixing from there?  (Or does NGPT already fix this?)

* Rewrite Linux's setitimer(ITIMER_PROF,...) to set up an 
interval timer for all threads of the thread group.

* Implement the profil() system call from Solaris
( http://ua1vm.ua.edu/cgi-bin/man-cgi?profil+2 )

What's your favorite idea for getting profiling of
multithreaded programs working on Linux?

Thanks,
Dan

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Alan Cox]

> Here are a few alternate ideas off the top of my head:
> 
> * Rip out Linuxthreads, replace it with NGPT, and
> start fixing from there?  (Or does NGPT already fix this?)
> 
> * Rewrite Linux's setitimer(ITIMER_PROF,...) to set up an 
> interval timer for all threads of the thread group.
> 
> * Implement the profil() system call from Solaris
> ( http://ua1vm.ua.edu/cgi-bin/man-cgi?profil+2 )
> 
> What's your favorite idea for getting profiling of
> multithreaded programs working on Linux?

Kernel support is not needed  for this, do it in user space. Or prove it
has to be in kernel space

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Dan Kegel]

Alan Cox wrote:
> 
> > Here are a few alternate ideas off the top of my head:
> >
> > * Rip out Linuxthreads, replace it with NGPT, and
> > start fixing from there?  (Or does NGPT already fix this?)
> >
> > * Rewrite Linux's setitimer(ITIMER_PROF,...) to set up an
> > interval timer for all threads of the thread group.
> >
> > * Implement the profil() system call from Solaris
> > ( http://ua1vm.ua.edu/cgi-bin/man-cgi?profil+2 )
> >
> > What's your favorite idea for getting profiling of
> > multithreaded programs working on Linux?
> 
> Kernel support is not needed  for this, do it in user space. Or prove it
> has to be in kernel space

I'm all in favor of a userspace fix.  I suggested a patch
to glibc to fix this.  Ulrich rejected it; I'm trying
to coax out of him how he thinks profiling of multithreaded
programs on Linux should be fixed.

I hope we can all at least agree that
  cc foo.c -pg -pthread
  ./a.out
  gprof a.out
should work in Linux without any workarounds on the part of the programmer...

- Dan


- Dan

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Alan Cox]

> I'm all in favor of a userspace fix.  I suggested a patch
> to glibc to fix this.  Ulrich rejected it; I'm trying
> to coax out of him how he thinks profiling of multithreaded
> programs on Linux should be fixed.

Good and I'll reject any kernel patches 8)

If Ulrich won't talk then talk to the NGPT people. Maybe a little
competition will warm things up.

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Jeff Garzik]

Alan Cox wrote:

>>I'm all in favor of a userspace fix.  I suggested a patch
>>to glibc to fix this.  Ulrich rejected it; I'm trying
>>to coax out of him how he thinks profiling of multithreaded
>>programs on Linux should be fixed.
>>
>
>Good and I'll reject any kernel patches 8)
>
>If Ulrich won't talk then talk to the NGPT people. Maybe a little
>competition will warm things up.
>
Talk about a small world, I just found out today someone I know has been 
maintaining the NGPT kernel patches :)

http://gtf.org/~dank/ngpt/

    Jeff

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[David Rees]

On Wed, Mar 13, 2002 at 09:55:01PM -0500, Jeff Garzik wrote:
>
> Talk about a small world, I just found out today someone I know has been 
> maintaining the NGPT kernel patches :)
> 
> http://gtf.org/~dank/ngpt/

It even looks like kernel support is included 2.4.19-pre3:

http://oss.software.ibm.com/pthreads/

But don't see anything about it in any of the recent change logs...

-Dave

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Dave McCracken]

--On Wednesday, March 13, 2002 07:26:56 PM -0800 David Rees
<dbr@greenhydrant.com> wrote:

> On Wed, Mar 13, 2002 at 09:55:01PM -0500, Jeff Garzik wrote:
>> 
>> Talk about a small world, I just found out today someone I know has been 
>> maintaining the NGPT kernel patches :)
>> 
>> http://gtf.org/~dank/ngpt/
> 
> It even looks like kernel support is included 2.4.19-pre3:
> 
> http://oss.software.ibm.com/pthreads/
> 
> But don't see anything about it in any of the recent change logs...

The relevant line from the changelog is:

- Signal changes for thread groups			(Dave McCracken)

This is the only patch that NGPT needs to work.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059

Re: libc/1427: gprof does not profile threads <synopsis of the problem

[Daniel Phillips]

On March 14, 2002 02:08 am, Dan Kegel wrote:
> Alan Cox wrote:
> > Kernel support is not needed  for this, do it in user space. Or prove it
> > has to be in kernel space
> 
> I'm all in favor of a userspace fix.  I suggested a patch
> to glibc to fix this.  Ulrich rejected it; I'm trying
> to coax out of him how he thinks profiling of multithreaded
> programs on Linux should be fixed.

I find it odd he vetoed your fix and didn't suggest an alternative.

/me checks to make sure this is cc'd to Ulrich.

-- 
Daniel