This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]