bug#63752: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE

[Eli Zaretskii <eliz@gnu.org>]

> From: Cyril Arnould <cyril.arnould@outlook.com>
> CC: "63752@debbugs.gnu.org" <63752@debbugs.gnu.org>,
> 	András Svraka <svraka.andras@gmail.com>
> Date: Fri, 30 Jun 2023 22:41:26 +0000
> 
> I've found that I can narrow it down similar to bug #63365: As long as I
> don't compile src/sysdep.c with -D_FORTIFY_SOURCE, the resulting
> binaries seem to behave normally. Does that maybe suggest an upstream
> problem? I compiled it as follows:
> 
> git clean -xdf
> git checkout emacs-28.2
> ./autogen.sh
> ./configure
> cd src
> make sysdep.o CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2'
> make sysdep.o -W sysdep.c
> cd ..
> make CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2'
> 
> I've attached the objects as well as their dumps in case anyone wants to
> take a look.

Thanks, but the differences are too large to figure out what causes
this.  It sounds like -D_FORTIFY_SOURCE=2 wraps and/or replaces many
library functions with special variants, and effect of that is
unclear, because the implementation of those wrappers is elsewhere
(probably in some library linked into the executable under that
option?).  E.g., by just looking at the diffs, it sounds like the
-D_FORTIFY_SOURCE=2 code doesn't call 'open' to open the null device??

Since you've already established sysdep.c alone is the culprit, I
suggest to narrow this.  Create a separate file sysdep1.c, move to it
the first portion of sysdep.c which includes everything before
serial_open, and build Emacs with these two parts (you'd need to add
sysdep1.o to base_obj in src/Makefile).  Once you have such an Emacs
successfully built and reproduce the problem, rebuild by compiling
sysdep1.c without -D_FORTIFY_SOURCE=2, and see if the problem goes
away.  If it does, bisect sysdep1.c by moving parts of it back to
sysdep.c, until you identify the smallest part of sysdep.c that needs
to be compiled with -D_FORTIFY_SOURCE=2 to reproduce the problem.
Then we will have to examine the effect of -D_FORTIFY_SOURCE=2 on that
smallest part, and see if we can figure this out.

This is a lot of work, so kudos if you are motivated to go ahead and
do it.  From my POV, the -D_FORTIFY_SOURCE=2 build is currently
problematic on Windows and therefore not supported by the upstream
project.  (IMNSHO, it is also wrong to use this in production builds
of programs such as Emacs, but that's me, and I know others disagree.)
My advice to MSYS2 folks at this time is to stop building Emacs that
way until the problem is resolved.