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


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.

OK.

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

..mark


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