Mail Archives: cygwin/2003/10/17/16:41:03
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 http://cygwin.com/contrib.html 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: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -