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

Mark Geisert mark@maxrnd.com
Tue Feb 23 07:36:00 GMT 2016

Hi Jon,

On Mon, 22 Feb 2016, Jon Turney wrote:
> Thanks for this.  A few comments inline.
> On 20/02/2016 08:16, Mark Geisert wrote:
>> +/* Called from profil.c to sample all non-main thread PC values for 
>> profiling */
>> +extern "C" void
>> +cygheap_profthr_all (void (*profthr_byhandle) (HANDLE))
>> +{
>> +  for (uint32_t ix = 0; ix < nthreads; ix++)
>> +    {
>> +      _cygtls *tls = cygheap->threadlist[ix].thread;
>> +      if (tls->tid)
>> +	profthr_byhandle (tls->tid->win32_obj_id);
>> +    }
>> +}
> 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.

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


More information about the Cygwin-patches mailing list