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 Fri, 17 Oct 2003, peter garrone wrote:

> Hi Brian
Hi Peter.  Seems like a private conversation, doesn't it? :)

>  Thanks very much for your comments.
You're welcome.

>  I think I have changed my approach so that it is broadly similar to
> your suggestions, but may differ in some details.
>  I have dropped the RNG. I dont think it is necessary or warranted.
I agree, especially in light of your new approach.

>  I have dropped the dll import library concept.
Probably good.  Although, it would still be neat to figure out a way to
trace back to the application "leaf" functions.  I guess that will be an
"exercise" for later.

>  I would agree that Corinna's suggestion about WaitForSingleObject is
> probably better, though I havent yet done it that way.
>  My current approach is to keep track of the time accumulated
> by each thread, and when it has exceeded the amount represented
> by a profiling period, assign the tick to the current PC,
> and subtract that amount of time from the running total for the
> thread. So it always adds up, anyway.
I was going to suggest this when we were talking about partial ticks, but
I was worried about charging time to the wrong PC.  Looking back, this
still fits in fine with the PC sampling "philosophy".

>  I still have it so that each thread that is to be profiled calls
> moncontrol(1). Also, an application compiled and linked without
> -pg could always use the "profil" call in a similar way.
> Each thread would call profil with identical parameters.
It should be simple to add an "all threads" mode later if we want, so this
is fine.  Does the main thread still call moncontrol(1) when compiled with
-pg?  I would think this would be required.

> To do the DLL's, I have added a linked list of profiling ranges
> to profil.c. These ranges are specified using an environment
> variable. The ranges may be DLL specific, or general memory ranges.
> There is a separate data file output upon program termination
> for each range, in addition to gmon.out.
The linked list sounds reasonable.  I guess if there were too many
threads, something less linear would be better.  Does anyone have a
suggestion about how to find these address ranges automatically (at least
for non dynamically loaded DLLs)?

I assume the gmon.out file contains just the original program proper
memory range?

I really wish we could get someone on the binutils list interested in
helping to extend the gmon.out file format to contain multiple hashes.  We
would still need a method to map the ranges to the DLLs.  Determining the
DLLs should be easy unless they were dynamically loaded.  You really
should send at least a ping over there, but you're doing all the work, so
I'll shut up now.

>  If a dll has not been stripped, gprof will use the data file
> and the dll to output a flat profile, but without call counts though.
> (At least this works with cygwin1.dll)
That sounds like it would be *really* usefull to cygwin developers!  This
concept was discussed before in the references I gave you, but never
pushed this far.

>  I have written a simple utility to summarise the information
> in these data files, giving flat addresses and CPU usage.
This sounds like a useful inclusion.  Again, it would be more functional
if we could feed all this into gprof and get partial call graphs.

Even if no one else comments, I really appreciate all this work you're
doing!  Also, thanks for continuing to send me the updated patches.  I
wish I had more time to look over them in detail right now.  I'll try and
do that soon.  I assume it is ok to give an open invitation for anyone
else who would like to give the a whirl?

BTW, if you are interested in contributing this, please take a look at the
"Before you get started" section of since
the assignment process can take some time.

Again, great work from my point of view!

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]