libgcov, fork, and mingw (and other targets without the full POSIX set)
I've received a report of a mingw build failure: ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of function 'fork' [-Wimplicit-function-declaration] 185 | pid = fork (); | ^~~~ make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 make[2]: *** Waiting for unfinished jobs As far as I understand it, mingw doesn't have fork and doesn't declare it in , so it's not clear to me how this has ever worked. I would expect a linker failure. Maybe that doesn't happen because the object containing a reference to fork is only ever pulled in if the application calls the intercepted fork, which doesn't happen on mingw. 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. Thanks, Florian
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
> Cc: Jonathan Yong <10wa...@gmail.com>, Jan Hubicka , Nathan > Sidwell > Date: Fri, 01 Dec 2023 09:02:55 +0100 > X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, > DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, > RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, > T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 > From: Florian Weimer via Gcc > > I've received a report of a mingw build failure: > > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of > function 'fork' [-Wimplicit-function-declaration] > 185 | pid = fork (); > | ^~~~ > make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 > make[2]: *** Waiting for unfinished jobs > > As far as I understand it, mingw doesn't have fork and doesn't declare > it in , so it's not clear to me how this has ever worked. I > would expect a linker failure. Maybe that doesn't happen because the > object containing a reference to fork is only ever pulled in if the > application calls the intercepted fork, which doesn't happen on mingw. > > 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 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.
Re: Update on GCC 14 C type safety changes/warnings as errors
Florian Weimer via Gcc writes: > [...] > Numbers do not tally up because one package can have multiple issues. > The autoconf column counts packages where file-name based heuristics > suggest the critical errors are in autoconf-style feature probes, where > they are ignored and could silently alter the results. My focus will be > on fixing those packages. incompatible-pointer-types at least suffers from some expected errors with e.g. strerror_r which you may want to just export the cache var for in a glibc environment at least for testing. Mine as well. > > These numbers include a certain amount of false positives, especially > for implicit-function-declaration and incompatible-pointer-types, but > the GCC instrumentation has improved somewhat and now uses unrelated > errors (e.g., about unknown types, or incorrect number of function > errors) to suppress logging of the critical errors. > > Looking at the numbers, everything seems quite doable except > incompatible-pointer-types. (Keep in mind that these numbers are based > on over 15,000 packages.) Instead of the incompatible-pointer-types > error, Clang only went with a subset (not yet implemented by GCC) called > incompatible-function-pointer-types, but I'm not sure if it would result > in a substantial amount of work reduction. The status as a warning for > non-function pointers definitely hides real bugs (for example, an > out-of-bounds write in PyTables on 32-bit architectures). > > I suggest we put in the incompatible-pointer-types upgrade for now > (pending review), and see how it goes in Fedora. I plan to backport > these changes to GCC 13 as used in our current development version, so > that we can gain some feedback from package maintainers before we import > GCC 14 (which is expected to happen well before the GCC upstream > release). If feedback is overly negative, I'm going to suggest that GCC > disables it again for the GCC 14 release, although that would run > counter to the request for one transition only. > > Thoughts? This sounds fair and in line with my observations. I lean towards us being able to pull it off but if needed, reverting that specific change later on in 14 development isn't the end of the world. Of course, you've added -fpermissive for a reason anyway, so we have that too. I hadn't considered exposing a patched GCC 13 to developers and might do the same, not sure how much take up there'd be on our end without some runtime toggle instead. Will have a think, but not really worried about it anyway, as the tinderboxes have great covergae & will run whatever version we want. > [...] Thank you again for doing this Florian. sam
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc wrote: > > I've received a report of a mingw build failure: > > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of > function 'fork' [-Wimplicit-function-declaration] > 185 | pid = fork (); > | ^~~~ > make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 > make[2]: *** Waiting for unfinished jobs > > As far as I understand it, mingw doesn't have fork and doesn't declare > it in , so it's not clear to me how this has ever worked. I > would expect a linker failure. Maybe that doesn't happen because the > object containing a reference to fork is only ever pulled in if the > application calls the intercepted fork, which doesn't happen on mingw. > > 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. This is wrapped inside #ifdef L_gcov_fork #endif grepping didn't find me what defines this, but it suggests the solution lies there ... Richard. > > Thanks, > Florian >
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
* Richard Biener: > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc wrote: >> >> I've received a report of a mingw build failure: >> >> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': >> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration >> of function 'fork' [-Wimplicit-function-declaration] >> 185 | pid = fork (); >> | ^~~~ >> make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 >> make[2]: *** Waiting for unfinished jobs >> >> As far as I understand it, mingw doesn't have fork and doesn't declare >> it in , so it's not clear to me how this has ever worked. I >> would expect a linker failure. Maybe that doesn't happen because the >> object containing a reference to fork is only ever pulled in if the >> application calls the intercepted fork, which doesn't happen on mingw. >> >> 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. > > This is wrapped inside > > #ifdef L_gcov_fork > #endif > > grepping didn't find me what defines this, but it suggests the solution > lies there ... That's just the general libgcc/ coding style, which puts multiple related functions into one C source file. The file is compiled multiple times with different -D options using Makefile rules like this one: $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c $(srcdir)/gcov.h $(srcdir)/libgcov.h $(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c It looks like this is done to emulate -Wl,--gc-sections without separate source files. Unfortunately, this is all built unconditionally. Thanks, Florian
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
在 2023/12/1 16:19, Eli Zaretskii via Gcc 写道: As far as I understand it, mingw doesn't have fork and doesn't declare it in , so it's not clear to me how this has ever worked. I would expect a linker failure. Maybe that doesn't happen because the object containing a reference to fork is only ever pulled in if the application calls the intercepted fork, which doesn't happen on mingw. That's correct. No program has been calling `fork()` in any way. 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 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. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer wrote: > > * Richard Biener: > > > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc > > wrote: > >> > >> I've received a report of a mingw build failure: > >> > >> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > >> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration > >> of function 'fork' [-Wimplicit-function-declaration] > >> 185 | pid = fork (); > >> | ^~~~ > >> make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 > >> make[2]: *** Waiting for unfinished jobs > >> > >> As far as I understand it, mingw doesn't have fork and doesn't declare > >> it in , so it's not clear to me how this has ever worked. I > >> would expect a linker failure. Maybe that doesn't happen because the > >> object containing a reference to fork is only ever pulled in if the > >> application calls the intercepted fork, which doesn't happen on mingw. > >> > >> 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. > > > > This is wrapped inside > > > > #ifdef L_gcov_fork > > #endif > > > > grepping didn't find me what defines this, but it suggests the solution > > lies there ... > > That's just the general libgcc/ coding style, which puts multiple > related functions into one C source file. The file is compiled multiple > times with different -D options using Makefile rules like this one: > > $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c > $(srcdir)/gcov.h $(srcdir)/libgcov.h > $(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c > > It looks like this is done to emulate -Wl,--gc-sections without separate > source files. Unfortunately, this is all built unconditionally. Hmm, so why's it then referenced and not "GCed"? The classical "solution" is to make the reference weak via sth like extern typeof(fork) fork () __attribute__((weak)); Richard. > Thanks, > Florian >
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
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
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
On Fri, 1 Dec 2023, Richard Biener via Gcc wrote: > On Fri, Dec 1, 2023 at 9:57 AM Florian Weimer wrote: > > > > * Richard Biener: > > > > > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc > > > wrote: > > >> > > >> I've received a report of a mingw build failure: > > >> > > >> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > > >> ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit > > >> declaration of function 'fork' [-Wimplicit-function-declaration] > > >> 185 | pid = fork (); > > >> | ^~~~ > > >> make[2]: *** [Makefile:932: _gcov_fork.o] Error 1 > > >> make[2]: *** Waiting for unfinished jobs > > >> > > >> As far as I understand it, mingw doesn't have fork and doesn't declare > > >> it in , so it's not clear to me how this has ever worked. I > > >> would expect a linker failure. Maybe that doesn't happen because the > > >> object containing a reference to fork is only ever pulled in if the > > >> application calls the intercepted fork, which doesn't happen on mingw. > > >> > > >> 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. > > > > > > This is wrapped inside > > > > > > #ifdef L_gcov_fork > > > #endif > > > > > > grepping didn't find me what defines this, but it suggests the solution > > > lies there ... > > > > That's just the general libgcc/ coding style, which puts multiple > > related functions into one C source file. The file is compiled multiple > > times with different -D options using Makefile rules like this one: > > > > $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c > > $(srcdir)/gcov.h $(srcdir)/libgcov.h > > $(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c > > > > It looks like this is done to emulate -Wl,--gc-sections without separate > > source files. Unfortunately, this is all built unconditionally. > > Hmm, so why's it then referenced and not "GCed"? On MinGW the corresponding .o file is not unpacked by the linker from libgcov.a when fork is not referenced, so it used to work fine. The problem is that now building the .o fails due to undeclared fork. > The classical "solution" is to make the reference weak via sth like > > extern typeof(fork) fork () __attribute__((weak)); This won't help here since fork is undeclared. Using __builtin_fork, as mentioned in adjacent sub-thread, should work. Alexander
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
在 2023/12/1 17:09, Richard Biener via Gcc 写道: Hmm, so why's it then referenced and not "GCed"? The classical "solution" is to make the reference weak via sth like extern typeof(fork) fork () __attribute__((weak)); There are issues about weak symbols on mingw targets. Calls to weak functions can jump to random, non-allocated memory and cause faults. Instead, duplicates of COMDAT sections are removed by the `.linkonce discard` directive. -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
On Dez 01 2023, Richard Biener via Gcc wrote: > Hmm, so why's it then referenced and not "GCed"? This has nothing to do with garbage collection. It's just the way libgcc avoids having too many source files. It would be exactly the same if every function were in its own file. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
> On Dez 01 2023, Richard Biener via Gcc wrote: > > > Hmm, so why's it then referenced and not "GCed"? > > This has nothing to do with garbage collection. It's just the way > libgcc avoids having too many source files. It would be exactly the > same if every function were in its own file. THe ifdef machinery makes every function to go insto its own .o file which are then archived. So if user code never calls to fork, the .o file with fork wrapper should not be picked by linker and we should not have link error. If user code calls fork, then the .o file with wrapper should be picked and we will get linker error on missing fork. So I think it ought to work as it is now. Does mingw linker behave somehow differently with archives? Or is there problem with a libgcov being DLL or something? Honza > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: libgcov, fork, and mingw (and other targets without the full POSIX set)
On Fri, Dec 01, 2023 at 01:03:01PM +0100, Jan Hubicka via Gcc wrote:
> > On Dez 01 2023, Richard Biener via Gcc wrote:
> >
> > > Hmm, so why's it then referenced and not "GCed"?
> >
> > This has nothing to do with garbage collection. It's just the way
> > libgcc avoids having too many source files. It would be exactly the
> > same if every function were in its own file.
>
> THe ifdef machinery makes every function to go insto its own .o file
> which are then archived. So if user code never calls to fork, the .o
> file with fork wrapper should not be picked by linker and we should not
> have link error.
>
> If user code calls fork, then the .o file with wrapper should be picked
> and we will get linker error on missing fork. So I think it ought to
> work as it is now. Does mingw linker behave somehow differently with
> archives? Or is there problem with a libgcov being DLL or something?
The problem is that the changes to switch to modern C result in calls to
unprototyped function being an error rather than just warning as before.
int foo (void) { return fork (); }
warning: implicit declaration of function ‘fork’
[-Wimplicit-function-declaration]
previously, now
error: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
(by default in C99+).
So, as has been discussed earlier, either we should use __builtin_fork ()
rather than fork (), or we need in configure to test for fork prototype and
if missing, prototype it ourselves, or ensure _gcov_fork.o is not compiled
on targets which don't have fork prototyped.
Jakub
gcc-12-20231201 is now available
Snapshot gcc-12-20231201 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20231201/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 17cbec6e8ea8817b6240837bb1f1bf74f1b9bdcd You'll find: gcc-12-20231201.tar.xz Complete GCC SHA256=04e4098a1a74575a5ee508e17a7b63965fa2f8507d8620fec9a234466865c6ac SHA1=abdb4127f32851e4a51f919537b75d287263f1ba Diffs from 12-20231124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
