This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is multithreaded profiling on cygwin possible?

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 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:
Problem reports:

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