Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

[Alexander Monakov <amonakov@ispras.ru>]

On Fri, 1 Dec 2023, LIU Hao via Gcc wrote:

> >> What's the best way to fix this?  I expect it's going to impact other
> >> targets (perhaps for different functions) because all of
> >> libgcov-interface.c is built unconditionally.  I don't think we run
> >> configure for the target, so we can't simply check for a definition of
> >> the HAVE_FORK macro.

I'm pretty sure configure runs for the target, but for musl-cross-make
it would be nice to limit it to declaration check rather than link test
(musl-cross-make installs libc headers, then configures and builds gcc
and libgcc just once, then builds libc, then builds the rest of gcc target
libraries, IIRC).

> > I'm not familiar with this code, so apologies in advance if what I
> > suggest below makes no sense.
> > 
> > If the code which calls 'fork' is never expected to be called in the
> > MinGW build, then one way of handling this is to define a version of
> > 'fork' that always fails, conditioned by a suitable #ifdef, so that
> > its declaration and definition are visible when this file is compiled.
> 
> Makes sense. The target-specific macro `_WIN32` serves that purpose.
> 
> However `fork()` doesn't actually exist there, and linking should indeed fail.
> Maybe `__gcov_fork()` shouldn't be defined at all.

A possible stop-gap solution is using __builtin_fork() instead.

Alexander