gprof profiling of multi-threaded Cygwin programs

[Mark Geisert]

On Thu, 18 Feb 2016, Jon Turney wrote:
> Thanks for this.
>
> On 17/02/2016 05:28, Mark Geisert wrote:
>> There is a behavioral change that ought to be documented somewhere:  If
>> a gmon.out file exists when a profiled application exits, the app will
>> now dump its profiling info into another file gmon.outXXXXXX where
>> mkstemp() replaces the Xs with random alphanumerics.  I added this
>> functionality to allow a profiled program to fork() yet retain profiling
>> info for both parent and child.  The old behavior was to simply
>> overwrite any existing gmon.out file.
>
> Did you consider making the filename deterministic (e.g. based on pid or 
> such) rather than random?

Yes, I considered using pid and/or exename to avoid collisions.  There was 
an issue with Cygwin long ago about pids being reused too quickly 
(actually Windows reusing pids too quickly) but that's been cured?

Maybe something like what's used to name core files on Linux would be 
preferable to using mkstemp().  IIRC that's core.exename.pid.

> With a random filename, if you have a process which forks more than once, 
> working out which gmon.out* file corresponds to which process could be 
> tricky.

Acknowledged.  Even with pids it may not be easy.. the files are created 
and written to at process exit so one is always going to be a bit lost 
working out which file belongs to which process.  But the pid values are 
certainly easier to type than six random alphanumerics :).

> A brief search tells me that apparently glibc supports the (undocumented) 
> GMON_OUT_PREFIX env var which enables a similar behaviour.

Ah, I did not know about that.  It would be easy to implement.

So I'm leaning towards choosing file name as GMON_OUT_PREFIX.exename.pid 
with GMON_OUT_PREFIX defaulting to "gmon.out" if unspecified.

Do you think the expanded name should be used in all cases, or only when 
there's a gmon.out already present?

..mark