This is the mail archive of the
mailing list for the Cygwin project.
child process initialization as part of fork()
- From: Mark Geisert <mark at maxrnd dot com>
- To: cygwin-developers at cygwin dot com
- Date: Mon, 7 Mar 2016 20:09:19 -0800 (PST)
- Subject: child process initialization as part of fork()
- Authentication-results: sourceware.org; auth=none
I've finally figured out why my recent profiling updates don't often work
for the case of a profiled program fork()ing with both parent and child
continuing on until exit without exec()ing. There is some static data in
libgmon.a that needs updating to be correct in the child after a fork().
I would like to make use of gcrt0.c's _monstartup() to determine when the
data needs to be updated, but there's a catch.
_monstartup() is declared "__attribute__((__constructor__))" which is
ideal for my purposes. But investigation has revealed that during fork()
the constructor is being run by the parent process, rather than the child
process as one would expect.
Is this behavior required by the current fork() implementation? Some kind
of chicken-and-egg problem avoidance maybe?
I suspect changing gmon from a static library to a DLL and using NO_COPY
could avoid the issue but that has a performance impact I'd like to avoid.