Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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: <20031013224718.17982.qmail@linuxmail.org> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "peter garrone" To: "Brian Ford" Cc: cygwin AT cygwin DOT com Date: Tue, 14 Oct 2003 06:47:18 +0800 Subject: Re: Is multithreaded profiling on cygwin possible? X-Originating-Ip: 192.10.200.223 X-Originating-Server: ws5-8.us4.outblaze.com ----- Original Message ----- From: Brian Ford Date: Mon, 13 Oct 2003 14:36:34 -0500 (CDT) To: peter garrone Subject: Re: Is multithreaded profiling on cygwin possible? > On Mon, 13 Oct 2003, peter garrone wrote: > > > > 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? A list of active threads is maintained. A thread calling moncontrol(1) gets put in the list. When a call to SuspendThread fails, the thread is assumed to be defunct and taken off the list. One of the fields in the thread is a counter corresponding to the sum of cpu returned by GetThreadTimes. This function has fields corresponding to kernel cpu and user cpu. The amount of time consumed by every thread is saved. Generally only one thread will have consumed CPU. However to be general, and in case the profiling thread is inadvertently delayed, all threads are considered. There is a partial tick problem. Suppose that a thread has consumed say 155% of the cpu time corresponding to a tick. I would assign one tick and use a local random number generator to assign an extra tick on average 55% of the time. I tried getting the program counter for all threads, but this was found not to work very well, consuming excessive cpu, on average 50 milliseconds. All the other calls were of the order of 1 microsecond. However getting the program counter only for any thread that used cpu according to GetThreadTimes appeared to take about 50 microseconds. Generally of course only one thread will have used CPU. The function GetThreadContext is used to obtain the PC. > > 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 would be interested if you would expand on this. Do you mean looking at the stack to find the calling function? > 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 > binutils AT sources DOT redhat DOT com for a general solution since they "own" gprof. > I am thinking of implementing a separate profil call so that it can be used simultaneously with -pg compilation and linking. Also a "profile-dll" call so that profiling of the space occupied by a dll would occur. My problem with profiling the entire dll address space is 1) The necessity of recompiling dll's so that mapping and call counting is implemented 2) The difficulty of doing anything with propriety dll's 3) The size and sparsity of the resulting gmon.out data file. So I thought I would try attacking the problem using the import libraries. Perhaps it is a silly idea, but if it could be made to work it avoids these problems. If I can get it to work, I'll be back. Thanks -- ______________________________________________ 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/