Is multithreaded profiling on cygwin possible

[peter garrone]

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

Unfortunately I dont have any problems that this approach would address.
I am keeping a copy of my work so far, and would send it to anyone,
but I have no current plans to continue with it.

>>  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".

Yes. It does get a bit philosophical. The program being profiled must
be regarded as a random process in itself, so adding an RNG only confuses
the issue.

>
>>  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.

Yes. It links in a special crt program that calls moncontrol(1). On linux,
it is necessary to call getitimer/setitimer for each thread as discussed previously,
and with this code on cygwin moncontrol(1). But this allows a lot of flexibility.

>
>> 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?

Yes, from "text" to "etext", the static linked range.
This is as per the current gmon.c file, which I am not proposing to change.
If call counts were required, it is usually possible to link a cygwin dll
function statically, and that would produce the call counts.

>
>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.

As it pans out, it doesnt seem so necessary to me, because gprof profiles the un-stripped
DLL's as they are. gprof does one thing well, profiling a BFD, which is
sort of in line with the UNIX philosophy. All the profiling data exist
as separate files for the various profiling ranges. This way solves my current
profiling problems and gives me fine control. Why profile every DLL when
you may only be interested in one? But it is absolutely essential to me
to be able to profile selected memory ranges.

>
>>  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 must say that it was unforeseen by myself, and very easy, accidental almost.
I had to save the profiling data for raw address ranges in some format,
gmon.out being the logical one. That was all the work necessary. 
I wondered if gprof would work with that data, and it did.
I hope this is standard for gprof, as in it reads any BFD with symbolic information,
and not some kludge. I am not expert enough to know.

>
>>  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.

Sure, mayby a special flag to gprof saying to generate a flat raw output.
The code is preety simple.

>
>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?

Thanks, I'm only attempting to solve my own problems, which are severe.
My application is apparently spending 60% of its time executing where it
shouldnt be. So I'm not sure if the profiling is all there yet.
The hardest bit was getting the basic profiling engine going for multi-threaded
operation, which had
mostly been done already anyway for single-threaded operation by others.
I have posted the code to the group,
and am trying to get the simple release signed so I can officially contribute this.
Please do send it on.

 Peter


-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze

--
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/