[PATCH] gprof profiling of multi-threaded Cygwin programs, ver 2

Mark Geisert mark@maxrnd.com
Thu Feb 25 08:47:00 GMT 2016

On Tue, 23 Feb 2016, Corinna Vinschen wrote:
> On Feb 22 23:36, Mark Geisert wrote:
>> On Mon, 22 Feb 2016, Jon Turney wrote:
>>> There doesn't seem to be anything specific to profiling about this, so it
>>> could be written in a more generic way, as "call a callback function for
>>> each thread".
>> I saw your later conversation with Corinna on the list re why
>> cygwin_internal() is involved now.  (I too had stumbled over the
>> cygwin1.dll/libgmon.a gap when I started this work.)  Given the necessity of
>> the separation, does it still make sense to write a generic per-thread
>> callback mechanism and then make use of it for this patch, or is that
>> overkill?  I can't tell.
> One problem with a generic solution is to generalize the arguments to
> the called function.  IMHO, keep it as is for now.  If we ever need to
> make this generic we can still do it.


>>>> +	if ((prefix = getenv("GMON_OUT_PREFIX")) != NULL) {
>>> setup-env.xml might be an appropriate place to mention this environment
>>> variable.
>> I am now writing a gprof.xml that will be tied into the existing
>> programming.xml.  I plan to document GMON_OUT_PREFIX in gprof.xml.  Do you
>> think that's sufficient?
> A single paragraph in setup-env.xml pointing to gprof.xml might be
> helpful, I think.

Alright, I can do that as part of the separate doc patch that I'm working.

I ran into an issue while testing the profiling of programs that fork() 
but don't exec().  So it may be a short while before I can send ver 3. 
Just FYI.


More information about the Cygwin-patches mailing list