Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs
Date: Mon, 13 Oct 2003 14:36:34 -0500 (CDT)
From: Brian Ford <ford AT vss DOT fsi DOT com>
X-X-Sender: ford AT eos
To: peter garrone <pgarrone AT linuxmail DOT org>
cc: cygwin AT cygwin DOT com
Subject: Re: Is multithreaded profiling on cygwin possible?
In-Reply-To: <20031013081818.16448.qmail@linuxmail.org>
Message-ID: <Pine.GSO.4.56.0310131410140.791@eos>
References: <20031013081818 DOT 16448 DOT qmail AT linuxmail DOT org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 13 Oct 2003, peter garrone wrote:

> As you have suggested, I have tried setting up a list of
> threads in profil.c, calling SuspendThread,
> GetThreadTimes, to get timing information for all threads,
> and to create a reasonably accurate profile for non-dll user space
> using gprof.
>
Sounds good, although I'm not quite sure I understand the implementation.
What you really need to know is what thread was running just before the
sampling thread so that it can sample the correct thread's PC.  How are
you using GetThreadTimes for this?

> My plan now is to create new dll import libraries so that when these
> dll functions are called, a flag is set in the thread structure list,
> and the profiling thread assigns cpu ticks against the statically linked
> small import functions, so that hopefully gprof will pick it up and
> assign some sort of cpu usage and call frequency count to all the
> functions in the import libraries.
>
> If you can see any obvious pitfalls with this approach, I would be grateful.
>
Using a flag in a structure list sounds like you're asking for race
conditions with threads.

I tried using a backtrace method to map the sampling time onto
DLL leaf functions (the import stubs) once, but it did not seem possible
to perfect.  Also, that is not always what you want.

I don't have any good suggestions or pitfalls to point out.

But, if you want this to be usefull for the community at large, attacking
the two points in the previous email directly would probably be more
useful.  ie. Figure out a way to store the samples using a
non-contiguous address space model, and modify gprof to load the symbol
tables for the dependent DLLs (gdb does this to some extent).  Note that
UNIX shared libraries have similar issues.  You may want to consult with
binutils AT sources DOT redhat DOT com for a general solution since they "own" gprof.

If you're just doing this for your own use, go for it.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/