[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?
..mark
More information about the Cygwin-patches
mailing list