child process initialization as part of fork()

[Mark Geisert <mark at maxrnd dot com>]

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.
Thanks,

..mark