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] |
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] |