delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2003/10/17/02:02:55

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
Message-ID: <20031017060238.6175.qmail@linuxmail.org>
MIME-Version: 1.0
From: "peter garrone" <pgarrone AT linuxmail DOT org>
To: "Brian Ford" <ford AT vss DOT fsi DOT com>
Cc: cygwin AT cygwin DOT com
Date: Fri, 17 Oct 2003 14:02:38 +0800
Subject: Re: Is multithreaded profiling on cygwin possible?
X-Originating-Ip: 192.10.200.223
X-Originating-Server: ws5-3.us4.outblaze.com

Hi Brian
 
 Thanks very much for your comments.

 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 have dropped the dll import library concept.

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

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.

 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)

 I have written a simple utility to summarise the information
in these data files, giving flat addresses and CPU usage.

 Peter Garrone


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019