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

From: Cyril Arnould <[email-masked]>
Date: Wed, 5 Jul 2023 20:23:33 +0000

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

Thanks for the pointers! Following your advice, the first sysdep1.c with
code up until serial_open was working quite quickly. On a hunch, I've
singled out the emacs_intr_read function and got lucky: If I only put
the emacs_intr_read, emacs_read and emacs_read_quit functions into
sysdep1.c, the problems go away if sysdep1.o is compiled without
-D_FORTIFY_SOURCE=2.

Aside from those functions, sysdep1.c also contains all of the includes
of the original file; I figured it doesn't make much sense to narrow
those down further. I also had to add the MAX_RW_COUNT
definition. There's a patch attached; it can be tested as follows:

git clean -xdf
git checkout emacs-28.2
patch -p1 -i 0001-Single-out-emacs_read-as-culprit.patch
./autogen.sh
./configure
make CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2'
# The following command will result in an Emacs window where the
# asynchronous process doesn't terminate:
./src/emacs -Q --eval '(async-shell-command "dir")'
cd src
make sysdep1.o -W sysdep1.c
cd ..
make CFLAGS='-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=2'
# This time the process will terminate:
./src/emacs -Q --eval '(async-shell-command "dir")'

I've also attached another archive with the objects, dumps and
diff. This time it seems like the entire file is different. Is it
possible that GCC messes up with the read function that gets defined to
sys_read at the top?

> 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.)

Fully understand, I really appreciate you helping despite the problem
being of low priority.

> My advice to MSYS2 folks at this time is to stop building Emacs that
> way until the problem is resolved.

The current release of Emacs on MSYS2 is indeed built without
-D_FORTIFY_SOURCE.