GNU bug report logs -
#63365
30.0.50; GCC 13.1 breaks building Emacs with native-compilation
Previous Next
Reported by: Arash Esbati <arash <at> gnu.org>
Date: Mon, 8 May 2023 08:17:02 UTC
Severity: normal
Tags: moreinfo
Merged with 65727
Found in version 30.0.50
Done: Andrea Corallo <acorallo <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63365 in the body.
You can then email your comments to 63365 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 08 May 2023 08:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Arash Esbati <arash <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 08 May 2023 08:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi all,
I'm on Win10 with Msys2/MinGW64 and GCC 13.1 landed on my HD. Now Emacs
doesn't build anymore when I pass '--with-native-compilation' to
configure. In summary (tried with master 3adc1e7f37):
$ git clone --depth=1 https://git.savannah.gnu.org/git/emacs.git emacs-build-test
$ cd emacs-build-test
$ ./autogen.sh
$ ./configure --with-native-compilation
$ make
Works with
gcc.exe (Rev7, Built by MSYS2 project) 12.2.0
and breaks with
gcc.exe (Rev4, Built by MSYS2 project) 13.1.0
emitting
--8<---------------cut here---------------start------------->8---
ELC+ELN ../lisp/font-core.elc
ELC+ELN ../lisp/font-lock.elc
ELC+ELN ../lisp/format.elc
ELC+ELN ../lisp/frame.elc
Error: wrong-type-argument ("../lisp/frame.el" number-or-marker-p
Backtrace:
00007ff6e577a12e
00007ff6e5648be1
00007ff6e5669601
00007ff6e57de84a
00007ff9b7977ff0
00007ff9b81b23d7
00007ff9b816149c
00007ff9b81b0f06
00007ff6e56ffc23
00007ff6e5701300
00007ff6e56dc492
00007ff6e56dd3e5
00007ff6e56d80fa
00007ff6e56d8448
00007ff6e56d8af9
00007ff6e56d9725
00007ff6e56d9979
00007ff6e56d80fa
00007ff996e9af72
00007ff6e56d80fa
00007ff996e9c1a7
00007ff6e56d80fa
00007ff996e9c3ad
00007ff6e56d80fa
00007ff6e56dc0f6
00007ff6e56dce05
00007ff6e56dc2bf
00007ff6e56dce95
00007ff6e56dc2bf
00007ff6e56de205
00007ff6e56dc2bf
00007ff6e56dccb5
00007ff6e56dc2bf
00007ff6e56de205
00007ff6e56dc2bf
00007ff6e56dc5e5
00007ff6e56dc2bf
00007ff6e56dc2bf
00007ff6e56ddded
00007ff6e56dc2bf
00007ff6e56ddded
00007ff6e56dc2bf
00007ff6e56dd3e5
00007ff6e56dd9d6
00007ff6e56dbc5d
00007ff6e56ddded
00007ff6e56dc2bf
00007ff6e56dd3e5
00007ff6e56dd9d6
00007ff6e56dbc5d
00007ff6e56de3ae
00007ff6e56dc2bf
00007ff6e56ddded
00007ff6e56dc2bf
00007ff6e56dce05
00007ff6e56dc2bf
00007ff6e56dd3e5
00007ff6e56dd9d6
00007ff6e56dbc5d
00007ff6e56de9aa
00007ff6e56d6735
00007ff6e5649fb5
...
make[3]: *** [Makefile:283: ../lisp/frame.elc] Error 3
make[2]: *** [Makefile:842: ../lisp/frame.elc] Error 2
make[2]: Leaving directory '/z/emacs-build-test/src'
make[1]: *** [Makefile:544: src] Error 2
make[1]: Leaving directory '/z/emacs-build-test'
make[1]: Entering directory '/z/emacs-build-test'
***
*** "make all" failed with exit status 2.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
*** to further investigate the problem
***
make[1]: *** [Makefile:414: advice-on-failure] Error 2
make[1]: Leaving directory '/z/emacs-build-test'
make: *** [Makefile:370: all] Error 2
--8<---------------cut here---------------end--------------->8---
I haven't tried "make V=1" yet.
Building Emacs with
$ git clone --depth=1 https://git.savannah.gnu.org/git/emacs.git emacs-build-test
$ cd emacs-build-test
$ ./autogen.sh
$ ./configure --without-native-compilation
$ make
is successful with GCC 13.1, OTOH.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 08 May 2023 11:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Date: Mon, 08 May 2023 10:16:31 +0200
>
> --8<---------------cut here---------------start------------->8---
> ELC+ELN ../lisp/font-core.elc
> ELC+ELN ../lisp/font-lock.elc
> ELC+ELN ../lisp/format.elc
> ELC+ELN ../lisp/frame.elc
>
> Error: wrong-type-argument ("../lisp/frame.el" number-or-marker-p
> Backtrace:
> 00007ff6e577a12e
> 00007ff6e5648be1
> 00007ff6e5669601
> 00007ff6e57de84a
> 00007ff9b7977ff0
These addresses are not useful anywhere but on your system. So either
run this command under GDB and post a human-readable source-level
backtrace, or at least convert the above list of addresses to a list
of file names, function names, and line numbers as explained in the
node "Crashing" of the Emacs user manual.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 08 May 2023 14:38:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> These addresses are not useful anywhere but on your system. So either
> run this command under GDB and post a human-readable source-level
> backtrace,
Thank. I tried that, i.e.,
$ ./autogen.sh
$ ./configure --with-native-compilation
$ gdb
$ (gdb) make
But backtrace in gdb returns nothing (nothing on stack IIRC). Do I have
to do something else?
> or at least convert the above list of addresses to a list of file
> names, function names, and line numbers as explained in the node
> "Crashing" of the Emacs user manual.
The recipe from the manual[1] doesn't work since:
$ sed -n 's/.*\[\(.*\)]$/\1/p' lisp/emacs_backtrace.txt
prints nothing on addresses like:
00007ff67feca12e
00007ff67fd98be1
00007ff67fdb9601
Am I missing something?
Another observation after reading etc/DEBUG: The build is successful if
I follow the advice there and do:
$ ./configure --with-native-compilation CFLAGS='-O0 -g3'
Does this make sense?
Best, Arash
Footnotes:
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Crashing.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 08 May 2023 15:13:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: Andrea Corallo <akrl <at> sdf.org>, 63365 <at> debbugs.gnu.org
> Date: Mon, 08 May 2023 16:36:57 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > These addresses are not useful anywhere but on your system. So either
> > run this command under GDB and post a human-readable source-level
> > backtrace,
>
> Thank. I tried that, i.e.,
>
> $ ./autogen.sh
> $ ./configure --with-native-compilation
> $ gdb
> $ (gdb) make
>
> But backtrace in gdb returns nothing (nothing on stack IIRC). Do I have
> to do something else?
Yes, of course. The GDB command "make" doesn't run anything under the
debugger, it is just a conveniency for rebuilding a program without
exiting GDB.
What you need is to run Emacs under GDB while it (Emacs) executes the
command which crashes. To find out what is that crashing command, you
should say:
$ make V=1
(note: "make", not "make -jN"!). Then wait for the crash. The
(longish) command shown by Make immediately before the crash is the
command that you want; copy it into the clipboard, and then do
$ cd /path/to/emacs/src
$ gdb ./emacs.exe
...
(gdb) cd ../lisp
(gdb) run <paste here the crashing command you copied>
and wait for the crash. Then:
(gdb) thread 1
(gdb) bt
Note: the command you copy into the clipboard may need massaging
before you can paste it to the GDB prompt: remove any stray newlines
and backslashes that escape newlines etc. Use some editor for that:
either (an older) Emacs or even Notepad.
> > or at least convert the above list of addresses to a list of file
> > names, function names, and line numbers as explained in the node
> > "Crashing" of the Emacs user manual.
>
> The recipe from the manual[1] doesn't work since:
>
> $ sed -n 's/.*\[\(.*\)]$/\1/p' lisp/emacs_backtrace.txt
>
> prints nothing on addresses like:
>
> 00007ff67feca12e
> 00007ff67fd98be1
> 00007ff67fdb9601
>
> Am I missing something?
The recipe goes like this:
sed -n 's/.*\[\(.*\)]$/\1/p' BACKTRACE | addr2line -C -f -i -p -e BINDIR/EMACS-BINARY
(It is broken in the manual into two lines, because the line is long,
but it is a single long command that runs Sed and pipes its output
into addr2line, a program that comes with GNU Binutils.)
> Another observation after reading etc/DEBUG: The build is successful if
> I follow the advice there and do:
>
> $ ./configure --with-native-compilation CFLAGS='-O0 -g3'
>
> Does this make sense?
It probably means this is a GCC bug that rears its ugly head when you
compile with optimizations.
Can you show a full C compilation command of one of the C source
files? Like this:
$ cd /path/to/emacs/src
$ make data.o -W data.c V=1
I'd like to see all of the compiler's command-line options your build
uses.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 08 May 2023 19:36:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> What you need is to run Emacs under GDB while it (Emacs) executes the
> command which crashes. To find out what is that crashing command, you
> should say:
>
> $ make V=1
Thanks for the detailed instructions; I will play with it, not there yet.
> The recipe goes like this:
>
> sed -n 's/.*\[\(.*\)]$/\1/p' BACKTRACE | addr2line -C -f -i -p -e BINDIR/EMACS-BINARY
>
> (It is broken in the manual into two lines, because the line is long,
> but it is a single long command that runs Sed and pipes its output
> into addr2line, a program that comes with GNU Binutils.)
Yes, I think I grasped that one. The problem I'm facing is that my
lisp/emacs_backtrace.txt looks like this:
Backtrace:
00007ff61166a12e
00007ff611538be1
00007ff611559601
00007ff6116ce84a
00007ff9b7977ff0
...
and the sed command doesn't match on the addresses above. It works for
the example given in the manual like this:
Backtrace:
emacs[0x5094e4]
emacs[0x4ed3e6]
emacs[0x4ed504]
/lib64/libpthread.so.0[0x375220efe0]
/lib64/libpthread.so.0(read+0xe)[0x375220e08e]
emacs[0x509af6]
emacs[0x5acc26]
So in my case, sed returns nothing which is piped into addr2line.
> Can you show a full C compilation command of one of the C source
> files? Like this:
>
> $ cd /path/to/emacs/src
> $ make data.o -W data.c V=1
>
> I'd like to see all of the compiler's command-line options your build
> uses.
It looks like this; line-breaks added manually:
--8<---------------cut here---------------start------------->8---
../lib-src/make-docfile -d . -g dispnew.o frame.o scroll.o \
xdisp.o menu.o window.o charset.o coding.o category.o ccl.o \
character.o chartab.o bidi.o term.o terminal.o xfaces.o \
emacs.o keyboard.o macros.o keymap.o sysdep.o bignum.o buffer.o \
filelock.o insdel.o marker.o minibuf.o fileio.o dired.o cmds.o \
casetab.o casefiddle.o indent.o search.o regex-emacs.o undo.o \
alloc.o pdumper.o data.o doc.o editfns.o callint.o eval.o \
floatfns.o fns.o sort.o font.o print.o lread.o emacs-module.o \
syntax.o bytecode.o comp.o dynlib.o process.o gnutls.o callproc.o \
region-cache.o sound.o timefns.o atimer.o doprnt.o intervals.o \
textprop.o composite.o xml.o lcms.o w32notify.o profiler.o \
decompress.o thread.o systhread.o sqlite.o treesit.o itree.o \
hbfont.o w32fns.o w32menu.o w32reg.o w32font.o w32term.o w32xfns.o \
w32select.o w32uniscribe.o w32cygwinx.o w32.o w32console.o \
w32heap.o w32inevt.o w32proc.o w32image.o fontset.o fringe.o \
image.o json.o > globals.tmp
../build-aux/move-if-change globals.tmp globals.h
echo timestamp > gl-stamp
gcc -c -mtune=generic \
-DUSE_CRT_DLL=1 \
-I /d/arash/Dev/Emacs/emacs-build-test/nt/inc -Demacs \
-I. -I. -I../lib -I../lib -mtune=generic \
-isystem C:/msys64/mingw64/include/librsvg-2.0 \
-isystem C:/msys64/mingw64/include/glib-2.0 \
-isystem C:/msys64/mingw64/lib/glib-2.0/include \
-isystem C:/msys64/mingw64/include/gdk-pixbuf-2.0 \
-isystem C:/msys64/mingw64/include/libpng16 \
-isystem C:/msys64/mingw64/include/webp \
-DLIBDEFLATE_DLL \
-isystem C:/msys64/mingw64/include/cairo \
-isystem C:/msys64/mingw64/include/freetype2 \
-isystem C:/msys64/mingw64/include/harfbuzz \
-isystem C:/msys64/mingw64/include/pixman-1 \
-isystem C:/msys64/mingw64/include/libxml2 \
-isystem C:/msys64/mingw64/include/webp \
-isystem C:/msys64/mingw64/include/harfbuzz \
-isystem C:/msys64/mingw64/include/freetype2 \
-isystem C:/msys64/mingw64/include/libpng16 \
-isystem C:/msys64/mingw64/include/glib-2.0 \
-isystem C:/msys64/mingw64/lib/glib-2.0/include \
-MMD -MF deps/data.d -MP \
-isystem C:/msys64/mingw64/include/p11-kit-1 \
-fno-common \
-Wall \
-Warith-conversion \
-Wdate-time \
-Wdisabled-optimization \
-Wdouble-promotion \
-Wduplicated-cond \
-Wextra \
-Wformat-signedness \
-Winit-self \
-Winvalid-pch \
-Wlogical-op \
-Wmissing-declarations \
-Wmissing-include-dirs \
-Wmissing-prototypes \
-Wnested-externs \
-Wnull-dereference \
-Wold-style-definition \
-Wopenmp-simd \
-Wpacked \
-Wpointer-arith \
-Wstrict-prototypes \
-Wsuggest-attribute=noreturn \
-Wsuggest-final-methods \
-Wsuggest-final-types \
-Wtrampolines \
-Wuninitialized \
-Wunknown-pragmas \
-Wunused-macros \
-Wvariadic-macros \
-Wvector-operation-performance \
-Wwrite-strings \
-Warray-bounds=2 \
-Wattribute-alias=2 \
-Wformat=2 \
-Wformat-truncation=2 \
-Wimplicit-fallthrough=5 \
-Wshift-overflow=2 \
-Wuse-after-free=3 \
-Wvla-larger-than=4031 \
-Wno-missing-field-initializers \
-Wno-override-init \
-Wno-sign-compare \
-Wno-type-limits \
-Wno-unused-parameter \
-Wno-format-nonliteral \
-Wno-bidi-chars \
-Wno-pointer-sign \
-g3 -O2 -gdwarf-2 data.c
--8<---------------cut here---------------end--------------->8---
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 09 May 2023 05:05:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: akrl <at> sdf.org, 63365 <at> debbugs.gnu.org
> Date: Mon, 08 May 2023 21:34:22 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > The recipe goes like this:
> >
> > sed -n 's/.*\[\(.*\)]$/\1/p' BACKTRACE | addr2line -C -f -i -p -e BINDIR/EMACS-BINARY
> >
> > (It is broken in the manual into two lines, because the line is long,
> > but it is a single long command that runs Sed and pipes its output
> > into addr2line, a program that comes with GNU Binutils.)
>
> Yes, I think I grasped that one. The problem I'm facing is that my
> lisp/emacs_backtrace.txt looks like this:
>
> Backtrace:
> 00007ff61166a12e
> 00007ff611538be1
> 00007ff611559601
> 00007ff6116ce84a
> 00007ff9b7977ff0
> ...
>
> and the sed command doesn't match on the addresses above. It works for
> the example given in the manual like this:
>
> Backtrace:
> emacs[0x5094e4]
> emacs[0x4ed3e6]
> emacs[0x4ed504]
> /lib64/libpthread.so.0[0x375220efe0]
> /lib64/libpthread.so.0(read+0xe)[0x375220e08e]
> emacs[0x509af6]
> emacs[0x5acc26]
>
> So in my case, sed returns nothing which is piped into addr2line.
Right, forgot about that factoid. On Windows, the Sed part is not
required, so the command is just
addr2line -C -f -i -p -e BINDIR/EMACS-BINARY < emacs_backtrace.txt
> > Can you show a full C compilation command of one of the C source
> > files? Like this:
> >
> > $ cd /path/to/emacs/src
> > $ make data.o -W data.c V=1
> >
> > I'd like to see all of the compiler's command-line options your build
> > uses.
>
> It looks like this; line-breaks added manually:
OK, so you compile with "-O2 -gdwarf-2 -g3", the default optimization
options, and with -mtune=generic (also the default). Things to try,
in order to better understand the scope of the problem:
1) try removing -mtune=generic
2) try using -O1 instead of -O2
For 1), edit src/Makefile to remove -mtune=generic from any GCC
options there, then remove src/*.o files and say "make" to rebuild.
For 2), edit src/Makefile to change -O2 to -O1, and again remove *.o
files and rebuild. But let's first establish the exact locus of the
crashes first, without any changes in the build options.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 09 May 2023 12:14:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Right, forgot about that factoid. On Windows, the Sed part is not
> required, so the command is just
>
> addr2line -C -f -i -p -e BINDIR/EMACS-BINARY < emacs_backtrace.txt
Tried this (with different setups, incl. adjusting sed to pipe the
addresses), and the result always looks like this:
?? ??:0
?? ??:0
?? ??:0
?? ??:0
?? ??:0
...
So that didn't work, for whatever reason :-(
> OK, so you compile with "-O2 -gdwarf-2 -g3", the default optimization
> options, and with -mtune=generic (also the default). Things to try,
> in order to better understand the scope of the problem:
>
> 1) try removing -mtune=generic
> 2) try using -O1 instead of -O2
>
> For 1), edit src/Makefile to remove -mtune=generic from any GCC
> options there, then remove src/*.o files and say "make" to rebuild.
> For 2), edit src/Makefile to change -O2 to -O1, and again remove *.o
> files and rebuild. But let's first establish the exact locus of the
> crashes first, without any changes in the build options.
Thanks, and I agree, let's keep the build options; I will try your
recipe for gdb next.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 09 May 2023 12:49:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: akrl <at> sdf.org, 63365 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 14:12:56 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Right, forgot about that factoid. On Windows, the Sed part is not
> > required, so the command is just
> >
> > addr2line -C -f -i -p -e BINDIR/EMACS-BINARY < emacs_backtrace.txt
>
> Tried this (with different setups, incl. adjusting sed to pipe the
> addresses), and the result always looks like this:
>
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ?? ??:0
> ...
??? Did you rebuild Emacs in-between? Or did you install Emacs with
something like "make install-strip", so the Emacs binary has no
symbols?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 10 May 2023 12:39:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> ??? Did you rebuild Emacs in-between? Or did you install Emacs with
> something like "make install-strip", so the Emacs binary has no
> symbols?
Yes, I built Emacs anew, but the recipe is always the same:
$ ./autogen.sh
$ ./configure --with-native-compilation
$ make
No installation, stripping, etc. and that gives me an emacs.exe of 137MB
size. If I strip and optimize, it is around 8.5MB.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 10 May 2023 12:48:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: akrl <at> sdf.org, 63365 <at> debbugs.gnu.org
> Date: Wed, 10 May 2023 14:37:55 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > ??? Did you rebuild Emacs in-between? Or did you install Emacs with
> > something like "make install-strip", so the Emacs binary has no
> > symbols?
>
> Yes, I built Emacs anew, but the recipe is always the same:
>
> $ ./autogen.sh
> $ ./configure --with-native-compilation
> $ make
>
> No installation, stripping, etc. and that gives me an emacs.exe of 137MB
> size. If I strip and optimize, it is around 8.5MB.
Did you submit to addr2line the 137MB binary or the stripped 8.5MB
binary? It sounds like you did that with the latter?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 10 May 2023 16:24:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Did you submit to addr2line the 137MB binary or the stripped 8.5MB
> binary? It sounds like you did that with the latter?
No, I tried many versions of passing the absolute path of src/emacs.exe
or relative one to addr2line; it (ideally) didn't pick up anything from
my $PATH. So I did things like:
$ addr2line -C -f -i -p -e src/emacs.exe < lisp/emacs_backtrace.txt
$ addr2line -C -f -i -p -e ../src/emacs.exe < emacs_backtrace.txt
$ addr2line -C -f -i -p -e `cygpath.exe -w -a src/emacs.exe` \
< lisp/emacs_backtrace.txt
...
The result was always the same.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 10 May 2023 16:54:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: akrl <at> sdf.org, 63365 <at> debbugs.gnu.org
> Date: Wed, 10 May 2023 16:27:11 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Did you submit to addr2line the 137MB binary or the stripped 8.5MB
> > binary? It sounds like you did that with the latter?
>
> No, I tried many versions of passing the absolute path of src/emacs.exe
> or relative one to addr2line; it (ideally) didn't pick up anything from
> my $PATH. So I did things like:
>
> $ addr2line -C -f -i -p -e src/emacs.exe < lisp/emacs_backtrace.txt
> $ addr2line -C -f -i -p -e ../src/emacs.exe < emacs_backtrace.txt
> $ addr2line -C -f -i -p -e `cygpath.exe -w -a src/emacs.exe` \
> < lisp/emacs_backtrace.txt
> ...
>
> The result was always the same.
Maybe it's a bug in your addr2line, then. It works perfectly here,
FWIW.
Can you make the unstripped emacs.exe available for download
somewhere, along with the emacs_backtrace.txt produced by that same
binary? I'd like to take a look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 10 May 2023 19:08:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 10 May 2023 19:54:06 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Maybe it's a bug in your addr2line, then. It works perfectly here,
> FWIW.
>
> Can you make the unstripped emacs.exe available for download
> somewhere, along with the emacs_backtrace.txt produced by that same
> binary? I'd like to take a look.
Hmm... looking at the files you sent, I'm beginning to think something
is wrong with generating backtraces on MS-Windows in the 64-bit
builds. Maybe it has to do with ASLR, or maybe the code which
produces the backtrace is wrong in 64-bit executables.
I'd like to see the backtrace from GDB and compare the addresses there
with those in emacs_backtrace.txt. Did you try to run the crashing
command under GDB, as I described earlier?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 11 May 2023 10:06:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Wed, 10 May 2023 22:08:57 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> > Date: Wed, 10 May 2023 19:54:06 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > Maybe it's a bug in your addr2line, then. It works perfectly here,
> > FWIW.
> >
> > Can you make the unstripped emacs.exe available for download
> > somewhere, along with the emacs_backtrace.txt produced by that same
> > binary? I'd like to take a look.
>
> Hmm... looking at the files you sent, I'm beginning to think something
> is wrong with generating backtraces on MS-Windows in the 64-bit
> builds. Maybe it has to do with ASLR, or maybe the code which
> produces the backtrace is wrong in 64-bit executables.
Actually, I take this back: the addresses in emacs_backtrace.txt seem
reasonable, similar to addresses shown in GDB backtraces from a 64-bit
Windows build we have on the bug tracker.
So the suspicion goes back to addr2line, although I see the same
problem with my version, which I built myself and which works
flawlessly with the 32-bit MinGW build of Emacs.
> I'd like to see the backtrace from GDB and compare the addresses there
> with those in emacs_backtrace.txt. Did you try to run the crashing
> command under GDB, as I described earlier?
And also, please try the other method described in the manual:
The hexadecimal numbers are program addresses, which can be
associated with source code lines using a debugging tool. For
example, the GDB command ‘list *0x509af6’ prints the source-code
lines corresponding to the ‘emacs[0x509af6]’ entry.
So could you try this method with a couple of addresses shown in
emacs_backtrace.txt you have? Does "list *0xNNNNN" yield reasonable
source locations?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 May 2023 13:06:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I'd like to see the backtrace from GDB and compare the addresses there
> with those in emacs_backtrace.txt.
I will try that later.
> Did you try to run the crashing command under GDB, as I described
> earlier?
Yes, I did that now, and the result is odd. I did in the shell (master
branch, 0e4cc6a8bf):
• git clean -fdx
• ./autogen.sh
• ./configure --with-native-compilation
• make V=1
which ends with:
*** "make all" failed with exit status 2.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
*** to further investigate the problem
***
make[1]: *** [Makefile:414: advice-on-failure] Error 2
make[1]: Leaving directory '/z/path/to/emacs-build-test'
make: *** [Makefile:370: all] Error 2
Next, I inspected the build failures which look like this for example
(line breaks added manually)
'../src/emacs.exe' -batch --no-site-file --no-site-lisp \
--eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
--eval "(setq org--inhibit-version-check t)" \
-l comp -f batch-byte+native-compile obsolete/vip.el
Backtrace:
00007ff6ae7fa12e
00007ff6ae6c8be1
[...]
00007ff6ae75e9aa
...
make[3]: *** [Makefile:328: obsolete/vip.elc] Error 3
So I followed your advice and did:
• cd src/
• gdb ./emacs.exe
• (gdb) cd ../lisp
• (gdb) run -batch --no-site-file --no-site-lisp ... (as above)
which returns (line breaks added manually again):
Starting program: z:\path\to\emacs-build-test\src\emacs.exe \
-batch --no-site-file --no-site-lisp \
--eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
--eval "(setq org--inhibit-version-check t)" \
-l comp -f batch-byte+native-compile obsolete/vip.el
[New Thread 37728.0x6048]
[New Thread 37728.0x73cc]
[New Thread 37728.0x5e20]
[New Thread 37728.0x84c8]
[Thread 37728.0x84c8 exited with code 0]
[Thread 37728.0x6048 exited with code 0]
[Thread 37728.0x5e20 exited with code 0]
[Thread 37728.0x73cc exited with code 0]
[Inferior 1 (process 37728) exited normally]
Does this make sense? It seems that under GDB, it works fine and it
breaks during the normal compilation. I tried it for some other build
failures, they work under GDB.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 May 2023 13:42:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Fri, 26 May 2023 15:05:01 +0200
>
> '../src/emacs.exe' -batch --no-site-file --no-site-lisp \
> --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
> --eval "(setq org--inhibit-version-check t)" \
> -l comp -f batch-byte+native-compile obsolete/vip.el
>
> Backtrace:
> 00007ff6ae7fa12e
> 00007ff6ae6c8be1
> [...]
> 00007ff6ae75e9aa
> ...
> make[3]: *** [Makefile:328: obsolete/vip.elc] Error 3
>
> So I followed your advice and did:
>
> • cd src/
> • gdb ./emacs.exe
> • (gdb) cd ../lisp
> • (gdb) run -batch --no-site-file --no-site-lisp ... (as above)
>
> which returns (line breaks added manually again):
>
> Starting program: z:\path\to\emacs-build-test\src\emacs.exe \
> -batch --no-site-file --no-site-lisp \
> --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
> --eval "(setq org--inhibit-version-check t)" \
> -l comp -f batch-byte+native-compile obsolete/vip.el
> [New Thread 37728.0x6048]
> [New Thread 37728.0x73cc]
> [New Thread 37728.0x5e20]
> [New Thread 37728.0x84c8]
> [Thread 37728.0x84c8 exited with code 0]
> [Thread 37728.0x6048 exited with code 0]
> [Thread 37728.0x5e20 exited with code 0]
> [Thread 37728.0x73cc exited with code 0]
> [Inferior 1 (process 37728) exited normally]
>
> Does this make sense? It seems that under GDB, it works fine and it
> breaks during the normal compilation.
Yes, it's unfortunate.
So now converting the addresses from emacs_backtrace.txt manually is
the only way forward, it seems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 May 2023 19:23:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So now converting the addresses from emacs_backtrace.txt manually is
> the only way forward, it seems.
Thanks, so I did:
• cd emacs-build-test/src
• gdb ./emacs.exe
• (gdb) list *0x00007ff6ae7fa12e (taken from emacs_backtrace.txt)
but GBD returns nothing. Is there any other recipe to this?
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 27 May 2023 06:01:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Fri, 26 May 2023 21:21:58 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > So now converting the addresses from emacs_backtrace.txt manually is
> > the only way forward, it seems.
>
> Thanks, so I did:
>
> • cd emacs-build-test/src
> • gdb ./emacs.exe
> • (gdb) list *0x00007ff6ae7fa12e (taken from emacs_backtrace.txt)
>
> but GBD returns nothing. Is there any other recipe to this?
Is this what you get for all the addresses in emacs_backtrace.txt?
Some of them, especially the ones close to the top, are expected to
yield nothing, but not all of them.
Also, try doing the same after letting the program run to the
beginning of the 'main' function, like this:
cd emacs-build-test/src
gdb ./emacs.exe
(gdb) start run -batch --no-site-file --no-site-lisp ...
(with the rest of the arguments you saw in the crashed command).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 27 May 2023 11:00:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Is this what you get for all the addresses in emacs_backtrace.txt?
> Some of them, especially the ones close to the top, are expected to
> yield nothing, but not all of them.
>
> Also, try doing the same after letting the program run to the
> beginning of the 'main' function, like this:
>
> cd emacs-build-test/src
> gdb ./emacs.exe
> (gdb) start run -batch --no-site-file --no-site-lisp ...
>
> (with the rest of the arguments you saw in the crashed command).
Ok, I tried it with the addresses emitted during compilation of
apropos.el and for some of them, the result of '(gdb) list *0xNNNN' is
attached. Is this what you're looking for? If so, I will do the
exercise for all of the addresses and post the result.
Best, Arash
[addresses.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 27 May 2023 11:34:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Sat, 27 May 2023 12:57:38 +0200
>
> > cd emacs-build-test/src
> > gdb ./emacs.exe
> > (gdb) start run -batch --no-site-file --no-site-lisp ...
> >
> > (with the rest of the arguments you saw in the crashed command).
>
> Ok, I tried it with the addresses emitted during compilation of
> apropos.el and for some of them, the result of '(gdb) list *0xNNNN' is
> attached. Is this what you're looking for? If so, I will do the
> exercise for all of the addresses and post the result.
Yes, please.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 27 May 2023 17:37:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Yes, please.
So these are the addresses I get for apropos.el:
--8<---------------cut here---------------start------------->8---
'../src/emacs.exe' -batch --no-site-file --no-site-lisp \
--eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
--eval "(setq org--inhibit-version-check t)" \
-l comp -f batch-byte+native-compile apropos.el
Backtrace:
00007ff75f71a12e
00007ff75f5e8be1
00007ff75f609601
00007ff75f77e84a
00007ffa21d07ff0
00007ffa21f923d7
00007ffa21f4149c
00007ffa21f90f06
00007ff75f66e1b0
00007ff75f6780fa
00007ff75f6786ca
00007ff9addf77d1
00007ff75f6780fa
00007ff75f6786ca
00007ff9addf78e0
00007ff75f6780fa
00007ff9add42e69
00007ff75f6780fa
00007ff9add4573b
00007ff75f6780fa
00007ff9add45692
00007ff75f6780fa
00007ff9ade068d2
00007ff75f67b88e
00007ff75f6780fa
00007ff9ade0599a
00007ff75f6780fa
00007ff9ade0257b
00007ff75f67b88e
00007ff75f6c3cb8
00007ff75f6780fa
00007ff9ade189ab
00007ff9ade18bff
00007ff9ade18f9a
00007ff75f6780fa
00007ff9ade00e6c
00007ff75f6780fa
00007ff9ade00cfe
00007ff75f6780fa
00007ff9addf1fab
00007ff75f6780fa
00007ff9ade00d96
00007ff75f6780fa
00007ff9addfee0c
00007ff75f6780fa
00007ff9addff82a
00007ff75f6780fa
00007ff9addfd95d
00007ff75f6780fa
00007ff9ade1c585
00007ff75f6780fa
00007ff9ade1bfff
00007ff75f6780fa
00007ff9adedc32f
00007ff75f6780fa
00007ff9ae7cf03b
00007ff75f6780fa
00007ff9ae7c724e
00007ff75f6780fa
00007ff9ae7c32b0
00007ff75f67c2aa
00007ff75f67e9aa
...
make[3]: *** [Makefile:328: apropos.elc] Error 3
--8<---------------cut here---------------end--------------->8---
The corresponding results from GDB are attached. The compilation breaks
for the following files:
apropos.el
checkdoc.el
obsolete/vip.el
progmodes/cc-langs.el
Do you need the information attached for all of the files above?
Best, Arash
[apropos.el.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sun, 28 May 2023 06:56:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Sat, 27 May 2023 19:35:12 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Yes, please.
>
> So these are the addresses I get for apropos.el:
>
> --8<---------------cut here---------------start------------->8---
> '../src/emacs.exe' -batch --no-site-file --no-site-lisp \
> --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" \
> --eval "(setq org--inhibit-version-check t)" \
> -l comp -f batch-byte+native-compile apropos.el
Thanks. It is a very strange crash, to say the least: we seem to
crash because we access an array out of its bounds or something.
Did you say that the problem goes away if you configure without
native-compilation? If so, let's wait for Andrea to fix the problems
with that on master, and try again.
Or did you also see similar problems on the emacs-29 branch?
If this is not related to native-compilation, my first suspect is GCC
optimizations. Try building with -Og or -O1, and see if that avoids
the problem. Or just downgrade to GCC 12 and wait for the GCC folks
to get their act together. (IME, using GCC version N.1 is not
recommended if you want to make sure your development environment
remains stable. This is especially true for platforms like
MS-Windows, which are not the main target for GCC development.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 08:43:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: András Svraka <svraka.andras <at> gmail.com>
> Date: Thu, 1 Jun 2023 09:37:26 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> Arash Esbati <arash <at> gnu.org>,
> akrl <at> sdf.org
>
> Thread 1 (Thread 6872.0xb48):
> #0 0x00007ffc3a8911c4 in win32u!NtUserWaitMessage () from C:\Windows\System32\win32u.dll
> #1 0x00007ffc3cbfb25c in USER32!EndDialog () from C:\Windows\System32\user32.dll
> #2 0x00007ffc3cbfb797 in USER32!EndDialog () from C:\Windows\System32\user32.dll
> #3 0x00007ffc3cc1ef66 in USER32!SoftModalMessageBox () from C:\Windows\System32\user32.dll
> #4 0x00007ffc3cc1d8a1 in USER32!DrawStateA () from C:\Windows\System32\user32.dll
> #5 0x00007ffc3cc1e695 in USER32!MessageBoxTimeoutW () from C:\Windows\System32\user32.dll
> #6 0x00007ffc3cc1e488 in USER32!MessageBoxTimeoutA () from C:\Windows\System32\user32.dll
> #7 0x00007ffc3cc1e09e in USER32!MessageBoxA () from C:\Windows\System32\user32.dll
> #8 0x00007ff6747977d5 in emacs_abort ()
> #9 0x00007ff674696308 in terminate_due_to_signal ()
> #10 0x00007ff6746af949 in deliver_fatal_thread_signal ()
This means Emacs crashed during native compilation, and is waiting for
"someone" to respond to the Abort dialog. Since you are running CI
unattended, it might be a good idea to modify lisp/Makefile to pass
--eval '(setq w32-disable-abort-dialog t)'
option on the batch compilation command line.
Why Emacs crashed is a separate issue:
> #11 0x00007ff6747f4992 in _gnu_exception_handler (exception_data=0x121dfa2d0) at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213
> #12 0x00007ffc3a7c55f0 in ucrtbase!__C_specific_handler () from C:\Windows\System32\ucrtbase.dll
> #13 0x00007ffc3d2643af in ntdll!.chkstk () from C:\Windows\SYSTEM32\ntdll.dll
> #14 0x00007ffc3d1f170e in ntdll!RtlVirtualUnwind2 () from C:\Windows\SYSTEM32\ntdll.dll
> #15 0x00007ffc3d2633be in ntdll!KiUserExceptionDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
> #16 0x00007ff6747359d1 in print_object ()
> #17 0x00007ff6747373a1 in Fprin1_to_string ()
> #18 0x00007ffc0e2c267b in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9 (par_0=0x19dd0292503, par_1=<optimized out>) from c:\_\B\src\build-UCRT64\native-lisp\28.2-16aa216e\byte-opt-9c5f25f5-718f7647.eln
> #19 0x00007ff67471640f in Ffuncall ()
> #20 0x00007ffc0e2c4007 in F627974652d6f7074696d697a652d666f726d_byte_optimize_form_0 (par_0=<optimized out>, par_1=0x0) from c:\_\B\src\build-UCRT64\native-lisp\28.2-16aa216e\byte-opt-9c5f25f5-718f764--Type <RET> for more, q to quit, c to continue without paging--c
> 7.eln
This tells that the crash was inside print_object, which was called by
prin1-to-string, probably because Emacs tried to print some invalid
Lisp object. Since there are no line numbers in the backtrace, I
cannot tell more.
I also understand that the crash is avoided by using lower
optimization levels, and perhaps other non-default GCC options could
be involved. So the jury is still out on whether this is an Emacs bug
or a (MinGW) GCC bug.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 10:32:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 63365 <at> debbugs.gnu.org (full text, mbox):
MSYS2 might have run into a related problem. Currently Emacs 28.2 cannot be built on the Github Actions CI with GCC 13.1 and native comp enabled because the build gets stuck during native compilation of files.el (all the other elisp files are compiled). I’ve attached a backtrace from the CI.
Meanwhile several people reported successfully building Emacs on their own machines from the same MSYS2 that runs in the CI. There’s a discussion on Github [1]. Downgrading to GCC 12.2 helps, and we’re still investigating the effects of various compiler switches.
[1]: https://github.com/msys2/MINGW-packages/issues/17374
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 10:32:03 GMT)
Full text and
rfc822 format available.
Message #77 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry, forgot the attachment.
[files.eln.log (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
> On 2023. Jun 1., at 9:31, András Svraka <svraka.andras <at> gmail.com> wrote:
>
> MSYS2 might have run into a related problem. Currently Emacs 28.2 cannot be built on the Github Actions CI with GCC 13.1 and native comp enabled because the build gets stuck during native compilation of files.el (all the other elisp files are compiled). I’ve attached a backtrace from the CI.
>
> Meanwhile several people reported successfully building Emacs on their own machines from the same MSYS2 that runs in the CI. There’s a discussion on Github [1]. Downgrading to GCC 12.2 helps, and we’re still investigating the effects of various compiler switches.
>
> [1]: https://github.com/msys2/MINGW-packages/issues/17374
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 10:32:03 GMT)
Full text and
rfc822 format available.
Message #80 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: András Svraka <svraka.andras <at> gmail.com>
>> Date: Thu, 1 Jun 2023 09:37:26 +0200
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> Arash Esbati <arash <at> gnu.org>,
>> akrl <at> sdf.org
>>
>> Thread 1 (Thread 6872.0xb48):
>> #0 0x00007ffc3a8911c4 in win32u!NtUserWaitMessage () from C:\Windows\System32\win32u.dll
>> #1 0x00007ffc3cbfb25c in USER32!EndDialog () from C:\Windows\System32\user32.dll
>> #2 0x00007ffc3cbfb797 in USER32!EndDialog () from C:\Windows\System32\user32.dll
>> #3 0x00007ffc3cc1ef66 in USER32!SoftModalMessageBox () from C:\Windows\System32\user32.dll
>> #4 0x00007ffc3cc1d8a1 in USER32!DrawStateA () from C:\Windows\System32\user32.dll
>> #5 0x00007ffc3cc1e695 in USER32!MessageBoxTimeoutW () from C:\Windows\System32\user32.dll
>> #6 0x00007ffc3cc1e488 in USER32!MessageBoxTimeoutA () from C:\Windows\System32\user32.dll
>> #7 0x00007ffc3cc1e09e in USER32!MessageBoxA () from C:\Windows\System32\user32.dll
>> #8 0x00007ff6747977d5 in emacs_abort ()
>> #9 0x00007ff674696308 in terminate_due_to_signal ()
>> #10 0x00007ff6746af949 in deliver_fatal_thread_signal ()
>
> This means Emacs crashed during native compilation, and is waiting for
> "someone" to respond to the Abort dialog. Since you are running CI
> unattended, it might be a good idea to modify lisp/Makefile to pass
>
> --eval '(setq w32-disable-abort-dialog t)'
>
> option on the batch compilation command line.
>
> Why Emacs crashed is a separate issue:
>
>> #11 0x00007ff6747f4992 in _gnu_exception_handler (exception_data=0x121dfa2d0) at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213
>> #12 0x00007ffc3a7c55f0 in ucrtbase!__C_specific_handler () from C:\Windows\System32\ucrtbase.dll
>> #13 0x00007ffc3d2643af in ntdll!.chkstk () from C:\Windows\SYSTEM32\ntdll.dll
>> #14 0x00007ffc3d1f170e in ntdll!RtlVirtualUnwind2 () from C:\Windows\SYSTEM32\ntdll.dll
>> #15 0x00007ffc3d2633be in ntdll!KiUserExceptionDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
>> #16 0x00007ff6747359d1 in print_object ()
>> #17 0x00007ff6747373a1 in Fprin1_to_string ()
>> #18 0x00007ffc0e2c267b in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9 (par_0=0x19dd0292503, par_1=<optimized out>) from c:\_\B\src\build-UCRT64\native-lisp\28.2-16aa216e\byte-opt-9c5f25f5-718f7647.eln
>> #19 0x00007ff67471640f in Ffuncall ()
>> #20 0x00007ffc0e2c4007 in
>> F627974652d6f7074696d697a652d666f726d_byte_optimize_form_0
>> (par_0=<optimized out>, par_1=0x0) from
>> c:\_\B\src\build-UCRT64\native-lisp\28.2-16aa216e\byte-opt-9c5f25f5-718f764--Type
>> <RET> for more, q to quit, c to continue without paging--c
>> 7.eln
>
> This tells that the crash was inside print_object, which was called by
> prin1-to-string, probably because Emacs tried to print some invalid
> Lisp object. Since there are no line numbers in the backtrace, I
> cannot tell more.
>
> I also understand that the crash is avoided by using lower
> optimization levels, and perhaps other non-default GCC options could
> be involved. So the jury is still out on whether this is an Emacs bug
> or a (MinGW) GCC bug.
Didn't had the time to follow this thread carefully, but I think would
be interesting to know if someone did try a native compiled Emacs on GCC
13.1.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 16:26:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: András Svraka <svraka.andras <at> gmail.com>
> Date: Thu, 1 Jun 2023 17:30:39 +0200
> Cc: 63365 <at> debbugs.gnu.org, arash <at> gnu.org, akrl <at> sdf.org
>
> > This tells that the crash was inside print_object, which was called by
> > prin1-to-string, probably because Emacs tried to print some invalid
> > Lisp object. Since there are no line numbers in the backtrace, I
> > cannot tell more.
>
> If I'm not mistaken, line numbers require a debug build. However, with a debug option compilation never got stuck.
Even with optimizations? And even with older versions of GCC? And
even with the default GCC options determined by the configure script?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 18:12:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> On 2023. Jun 1., at 10:42, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> This means Emacs crashed during native compilation, and is waiting for
> "someone" to respond to the Abort dialog. Since you are running CI
> unattended, it might be a good idea to modify lisp/Makefile to pass
>
> --eval '(setq w32-disable-abort-dialog t)'
>
> option on the batch compilation command line.
Ran a new build on the CI with this option. Compilation of files.el now properly fails with the following errors:
make[3]: *** [Makefile:298: ../../emacs-28.2/lisp/files.eln] Error 127
make[2]: *** [Makefile:813: ../../emacs-28.2/lisp/files.eln] Error 2
After which the build continues, and files.eln is skipped. The first line refers to lisp/Makefile, the second to src/Makefile, which launches the former. The CI produced a dump as well. Is that of any help?
https://github.com/svraka/MINGW-packages/actions/runs/5144666663/
> This tells that the crash was inside print_object, which was called by
> prin1-to-string, probably because Emacs tried to print some invalid
> Lisp object. Since there are no line numbers in the backtrace, I
> cannot tell more.
If I'm not mistaken, line numbers require a debug build. However, with a debug option compilation never got stuck.
András
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Jun 2023 18:12:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> On 2023. Jun 1., at 10:49, Andrea Corallo <acorallo <at> gnu.org> wrote:
>
> Didn't had the time to follow this thread carefully, but I think would
> be interesting to know if someone did try a native compiled Emacs on GCC
> 13.1.
>
> Andrea
It works on Windows with MSYS2, at least several people managed to build it on their machines. What we’re struggling with is building it in the GitHub CI for a release.
András
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 10:44:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Did you say that the problem goes away if you configure without
> native-compilation?
Yes, no problems when --without-native-compilation is passed to
configure.
> If so, let's wait for Andrea to fix the problems with that on master,
> and try again.
I tried the latest master (a902156068), and the issue remains.
> Or did you also see similar problems on the emacs-29 branch?
Yes, issue remains with 0eba9cf651.
> If this is not related to native-compilation, my first suspect is GCC
> optimizations. Try building with -Og or -O1, and see if that avoids
> the problem.
I will try the ideas above and report back.
> Or just downgrade to GCC 12 and wait for the GCC folks to get their
> act together. (IME, using GCC version N.1 is not recommended if you
> want to make sure your development environment remains stable. This
> is especially true for platforms like MS-Windows, which are not the
> main target for GCC development.)
It seams that downgrading to GCC 12 is the way. Upgrading from GCC 11
to 12 went really smooth, so I didn't expect this kind of issues. I
hope that someone more knowledgeable than me could report this to the
GCC folks so they can have a look at it.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 13:20:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Thu, 08 Jun 2023 12:21:11 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Did you say that the problem goes away if you configure without
> > native-compilation?
>
> Yes, no problems when --without-native-compilation is passed to
> configure.
>
> > If so, let's wait for Andrea to fix the problems with that on master,
> > and try again.
>
> I tried the latest master (a902156068), and the issue remains.
>
> > Or did you also see similar problems on the emacs-29 branch?
>
> Yes, issue remains with 0eba9cf651.
Andrea, can you suggest some ideas for what to try/test, or
alternatively how to prepare a concise test/reproducer for the GCC
folks? AFAIU, GCC 13.1 does work on GNU/Linux to produce a working
Emacs with native-compilation, so this is probably Windows-specific.
Arash, are you building with that _FORTIFY_SOURCE option that was
discussed in bug#63752? If so, please try without that (but still
with GCC 13.1).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 14:03:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arash Esbati <arash <at> gnu.org>
>> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
>> Date: Thu, 08 Jun 2023 12:21:11 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Did you say that the problem goes away if you configure without
>> > native-compilation?
>>
>> Yes, no problems when --without-native-compilation is passed to
>> configure.
>>
>> > If so, let's wait for Andrea to fix the problems with that on master,
>> > and try again.
>>
>> I tried the latest master (a902156068), and the issue remains.
>>
>> > Or did you also see similar problems on the emacs-29 branch?
>>
>> Yes, issue remains with 0eba9cf651.
>
> Andrea, can you suggest some ideas for what to try/test, or
> alternatively how to prepare a concise test/reproducer for the GCC
> folks? AFAIU, GCC 13.1 does work on GNU/Linux
I'm giving it a try mow to be sure.
> to produce a working
> Emacs with native-compilation, so this is probably Windows-specific.
I'd personally start producing an Emacs made only of bytecode but with
native compiler capabilies. To achieve this one can hack the Makefile
removing the native code specific parts, something like the very much
untested attached.
[build-hack.diff (text/x-diff, inline)]
diff --git a/lisp/Makefile.in b/lisp/Makefile.in
index 1e0935f565f..635dd7d1450 100644
--- a/lisp/Makefile.in
+++ b/lisp/Makefile.in
@@ -278,23 +278,9 @@ TAGS:
THEFILE = no-such-file
.PHONY: $(THEFILE)c
$(THEFILE)c:
-ifeq ($(HAVE_NATIVE_COMP),yes)
- $(AM_V_ELC)$(emacs) $(BYTE_COMPILE_FLAGS) \
- -l comp -f byte-compile-refresh-preloaded \
- -f batch-byte+native-compile $(THEFILE)
-else
$(AM_V_ELC)$(emacs) $(BYTE_COMPILE_FLAGS) \
-l bytecomp -f byte-compile-refresh-preloaded \
-f batch-byte-compile $(THEFILE)
-endif
-
-ifeq ($(HAVE_NATIVE_COMP),yes)
-.PHONY: $(THEFILE)n
-$(THEFILE)n:
- $(AM_V_ELN)$(emacs) $(BYTE_COMPILE_FLAGS) \
- -l comp -f byte-compile-refresh-preloaded \
- --eval '(batch-native-compile t)' $(THEFILE)
-endif
# Files MUST be compiled one by one. If we compile several files in a
# row (i.e., in the same instance of Emacs) we can't make sure that
@@ -323,11 +309,6 @@ .el.elc:
-l comp -f batch-byte-compile $<
TZ=UTC0 touch -t 197001010000 $@
else
-.el.elc:
- $(AM_V_ELC)$(emacs) $(BYTE_COMPILE_FLAGS) \
- -l comp -f batch-byte+native-compile $<
-endif
-else
.el.elc:
$(AM_V_ELC)$(emacs) $(BYTE_COMPILE_FLAGS) -f batch-byte-compile $<
endif
[Message part 3 (text/plain, inline)]
I'd also nil `native-comp-jit-compilation' in the early init.
After that one should still be able to run the native compiler testsuite
with say:
./src/emacs -batch -l ert -l test/src/comp-tests.el -f ert-run-tests-batch-and-exit
We want probably start running first all tests but the bootstrap one and
if they pass run this as well. At this point probably start reasoning
depending on the output.
Best Regards
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 14:19:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: Arash Esbati <arash <at> gnu.org>, 63365 <at> debbugs.gnu.org
> Date: Thu, 08 Jun 2023 10:02:22 -0400
>
> > Andrea, can you suggest some ideas for what to try/test, or
> > alternatively how to prepare a concise test/reproducer for the GCC
> > folks? AFAIU, GCC 13.1 does work on GNU/Linux
>
> I'm giving it a try mow to be sure.
Thanks, that'd be good.
> > to produce a working
> > Emacs with native-compilation, so this is probably Windows-specific.
>
> I'd personally start producing an Emacs made only of bytecode but with
> native compiler capabilies. To achieve this one can hack the Makefile
> removing the native code specific parts, something like the very much
> untested attached.
OK, but I thin Arash should try building without -D_FORTIFY_SOURCE=1
cpp option first. Because if that works, it then becomes a general
MinGW GCC problem with using that option, and not something specific
to Emacs or libgccjit.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 14:40:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: Arash Esbati <arash <at> gnu.org>, 63365 <at> debbugs.gnu.org
>> Date: Thu, 08 Jun 2023 10:02:22 -0400
>>
>> > Andrea, can you suggest some ideas for what to try/test, or
>> > alternatively how to prepare a concise test/reproducer for the GCC
>> > folks? AFAIU, GCC 13.1 does work on GNU/Linux
>>
>> I'm giving it a try mow to be sure.
>
> Thanks, that'd be good.
I confirm Emacs 29 bootstraps fine native compiled with GCC+libgccjit
13.1 x86_64-pc-linux-gnu here.
>> > to produce a working
>> > Emacs with native-compilation, so this is probably Windows-specific.
>>
>> I'd personally start producing an Emacs made only of bytecode but with
>> native compiler capabilies. To achieve this one can hack the Makefile
>> removing the native code specific parts, something like the very much
>> untested attached.
>
> OK, but I thin Arash should try building without -D_FORTIFY_SOURCE=1
> cpp option first. Because if that works, it then becomes a general
> MinGW GCC problem with using that option, and not something specific
> to Emacs or libgccjit.
Agree.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 22:29:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Arash, are you building with that _FORTIFY_SOURCE option that was
> discussed in bug#63752?
No, never used that option.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 08 Jun 2023 22:29:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> If this is not related to native-compilation, my first suspect is GCC
> optimizations. Try building with -Og or -O1, and see if that avoids
> the problem.
Ok, I tried the different optimization levels and this is the result.
Running the standard procedure
$ git clean -fdx
$ ./autogen.sh
$ ./configure --with-native-compilation
Gives this in the summary
What compiler should emacs be built with? gcc -g3 -O2 -gdwarf-2
which breaks during the make run.
Lowering the -O option works for these three scenarios and Emacs builds
successfully with GCC 13.1:
$ git clean -fdx
$ ./autogen.sh
$ CFLAGS='-g3 -O0 -gdwarf-2' ./configure --with-native-compilation
$ make
$ git clean -fdx
$ ./autogen.sh
$ CFLAGS='-g3 -O1 -gdwarf-2' ./configure --with-native-compilation
$ make
$ git clean -fdx
$ ./autogen.sh
$ CFLAGS='-g3 -Og -gdwarf-2' ./configure --with-native-compilation
$ make
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 16 Jun 2023 09:05:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've been playing around with compiler options. From my findings, the
-foptimize-sibling-calls flag breaks the build:
./autogen.sh
CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls' \
./configure --with-native-compilation
make
OTOH, using -O1 with every flag listed under -O2 *but*
-foptimize-sibling-calls results in the build succeeding. The following
works as well for me:
./autogen.sh
CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls' \
./configure --with-native-compilation
make
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 16 Jun 2023 10:32:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Cyril Arnould <cyril.arnould <at> outlook.com>
> CC: "eliz <at> gnu.org" <eliz <at> gnu.org>, "63365 <at> debbugs.gnu.org"
> <63365 <at> debbugs.gnu.org>, " akrl <at> sdf.org" <akrl <at> sdf.org>,
> András Svraka <svraka.andras <at> gmail.com>
> Date: Fri, 16 Jun 2023 09:04:16 +0000
>
> I've been playing around with compiler options. From my findings, the
>
> -foptimize-sibling-calls flag breaks the build:
>
>
>
> ./autogen.sh
>
> CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls' \
>
> ./configure --with-native-compilation
>
> make
>
>
>
> OTOH, using -O1 with every flag listed under -O2 *but*
>
> -foptimize-sibling-calls results in the build succeeding. The following
>
> works as well for me:
>
>
>
> ./autogen.sh
>
> CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls' \
>
> ./configure --with-native-compilation
>
> make
Andrea, any reason that this GCC switch should break
native-compilation? Does the same problem happen on GNU/Linux?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 16 Jun 2023 14:50:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Cyril Arnould <cyril.arnould <at> outlook.com>
>> CC: "eliz <at> gnu.org" <eliz <at> gnu.org>, "63365 <at> debbugs.gnu.org"
>> <63365 <at> debbugs.gnu.org>, " akrl <at> sdf.org" <akrl <at> sdf.org>,
>> András Svraka <svraka.andras <at> gmail.com>
>> Date: Fri, 16 Jun 2023 09:04:16 +0000
>>
>> I've been playing around with compiler options. From my findings, the
>>
>> -foptimize-sibling-calls flag breaks the build:
>>
>>
>>
>> ./autogen.sh
>>
>> CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls' \
>>
>> ./configure --with-native-compilation
>>
>> make
>>
>>
>>
>> OTOH, using -O1 with every flag listed under -O2 *but*
>>
>> -foptimize-sibling-calls results in the build succeeding. The following
>>
>> works as well for me:
>>
>>
>>
>> ./autogen.sh
>>
>> CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls' \
>>
>> ./configure --with-native-compilation
>>
>> make
>
> Andrea, any reason that this GCC switch should break
> native-compilation?
At this point I start to suspect that this is not strictly related to
native compilation.
The configure flags are used only for our regular C code and not for
Elisp native compilation. So it might be that some kind of
misscompilaiton of our C code is happening only with
--with-native-compilation, but looks to me it's not our compiler or
libgccjit the issue here.
> Does the same problem happen on GNU/Linux?
I tried now on GCC 13.1.1
git clean -xfd && ./autogen.sh
CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls'
./configure --with-native-compilation && make -j16
and have complete bootstrap succesfully on emacs-29 (65f355ea0a3), my
dev machine is still x86_64-pc-linux-gnu.
One idea might be asking GCC to log what optimize-sibling-calls is doing
and see if any of our C function supporting native compilation is
touched by this pass (I believe is called in GCC tree-tailcall).
CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls -fdump-tree-tailr' && make bootstrap
should let GCC dump what this pass is for each C compilation unit, I'd
start looking at the output for comp.c (I've comp.c.045t.tailr1 and comp.c.125t.tailr2).
Hope it helps!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 16 Jun 2023 14:53:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Cyril Arnould <cyril.arnould <at> outlook.com>
>>> CC: "eliz <at> gnu.org" <eliz <at> gnu.org>, "63365 <at> debbugs.gnu.org"
>>> <63365 <at> debbugs.gnu.org>, " akrl <at> sdf.org" <akrl <at> sdf.org>,
>>> András Svraka <svraka.andras <at> gmail.com>
>>> Date: Fri, 16 Jun 2023 09:04:16 +0000
>>>
>>> I've been playing around with compiler options. From my findings, the
>>>
>>> -foptimize-sibling-calls flag breaks the build:
>>>
>>>
>>>
>>> ./autogen.sh
>>>
>>> CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls' \
>>>
>>> ./configure --with-native-compilation
>>>
>>> make
>>>
>>>
>>>
>>> OTOH, using -O1 with every flag listed under -O2 *but*
>>>
>>> -foptimize-sibling-calls results in the build succeeding. The following
>>>
>>> works as well for me:
>>>
>>>
>>>
>>> ./autogen.sh
>>>
>>> CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls' \
>>>
>>> ./configure --with-native-compilation
>>>
>>> make
>>
>> Andrea, any reason that this GCC switch should break
>> native-compilation?
>
> At this point I start to suspect that this is not strictly related to
> native compilation.
>
> The configure flags are used only for our regular C code and not for
> Elisp native compilation. So it might be that some kind of
> misscompilaiton of our C code is happening only with
> --with-native-compilation, but looks to me it's not our compiler or
> libgccjit the issue here.
>
>> Does the same problem happen on GNU/Linux?
>
> I tried now on GCC 13.1.1
>
> git clean -xfd && ./autogen.sh
> CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls'
> ./configure --with-native-compilation && make -j16
>
> and have complete bootstrap succesfully on emacs-29 (65f355ea0a3), my
> dev machine is still x86_64-pc-linux-gnu.
>
> One idea might be asking GCC to log what optimize-sibling-calls is doing
> and see if any of our C function supporting native compilation is
> touched by this pass (I believe is called in GCC tree-tailcall).
>
> CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls -fdump-tree-tailr' && make bootstrap
>
> should let GCC dump what this pass is for each C compilation unit, I'd
> start looking at the output for comp.c (I've comp.c.045t.tailr1 and comp.c.125t.tailr2).
>
> Hope it helps!
>
> Andrea
Just to add...
Looking at GCC source code, one should be able to grep within those
files for "Found tail call " or "Eliminated tail recursion in bb" as a
marker of some optimization happening there :)
Best Regards
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 17 Jun 2023 08:23:04 GMT)
Full text and
rfc822 format available.
Message #125 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ok I ran the following, just to have a fresh start with the latest sources:
git clean -xdf
git switch emacs-29
git pull
./autogen.sh
export CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls -fdump-tree-tailr'
./configure --with-native-compilation
make
I couldn't find anything searching for the phrases you mentioned,
however. I also don't really know what to look for... I've tried to
gather all of the .tailr1 and .tailr2 files, you can find them
attached. I hope this helps.
[Message part 2 (text/html, inline)]
[tails.tar.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 20 Jun 2023 08:33:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
> Ok I ran the following, just to have a fresh start with the latest sources:
>
>
>
> git clean -xdf
>
> git switch emacs-29
>
> git pull
>
> ./autogen.sh
>
> export CFLAGS='-g3 -O1 -gdwarf-2 -foptimize-sibling-calls -fdump-tree-tailr'
>
> ./configure --with-native-compilation
>
> make
>
>
>
> I couldn't find anything searching for the phrases you mentioned,
>
> however. I also don't really know what to look for... I've tried to
>
> gather all of the .tailr1 and .tailr2 files, you can find them
>
> attached. I hope this helps.
Mmmhh that's bizarre, AFAIU -foptimize-sibling-calls only triggers in
the compiler tailr and if this does something it should dump one of the
mentioned phrases.
If -foptimize-sibling-calls is really the culprint we should see
something there... I must be missing something here.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 22 Jun 2023 20:36:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
> I've been playing around with compiler options. From my findings, the
>
> -foptimize-sibling-calls flag breaks the build:
Many thanks for digging into this. I can confirm that Emacs builds with
-fno-optimize-sibling-calls in CFLAGS. I have a script which (now)
does:
CFLAGS='-O3 -g0 -pipe -fno-optimize-sibling-calls' \
./configure ...
and it works again.
Now the question is: Is this considered a GCC bug and we should close
this report as notabug?
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 23 Jun 2023 05:33:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: "eliz <at> gnu.org" <eliz <at> gnu.org>, "63365 <at> debbugs.gnu.org"
> <63365 <at> debbugs.gnu.org>, " akrl <at> sdf.org" <akrl <at> sdf.org>,
> András Svraka
> <svraka.andras <at> gmail.com>
> Date: Thu, 22 Jun 2023 22:34:48 +0200
>
> Many thanks for digging into this. I can confirm that Emacs builds with
> -fno-optimize-sibling-calls in CFLAGS. I have a script which (now)
> does:
>
> CFLAGS='-O3 -g0 -pipe -fno-optimize-sibling-calls' \
> ./configure ...
>
> and it works again.
>
> Now the question is: Is this considered a GCC bug and we should close
> this report as notabug?
AFAIR, last Andrea looked into this he was surprised by this finding
and didn't understand how -foptimize-sibling-calls could cause such
problems. I hope Andrea will come up with some tests for you guys to
provide more information, so he does eventually understand the
cause(s). I don't think we can in good faith claim this is a GCC bug
before we understand the problem better.
Meanwhile, I'd like to consider a PROBLEMS entry about this, if that's
needed. Do I understand correctly that -fno-optimize-sibling-calls is
needed for successful building of Emacs 29.0.92 using MinGW64 GCC 13.1?
If so, I think we should have this in PROBLEMS.
Also, why are you using -O3? That is not recommended when building
Emacs. (But I understand that -foptimize-sibling-calls is in -O2, not
just in -O3, and so -fno-optimize-sibling-calls is needed even if
using -O2, right?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 23 Jun 2023 11:42:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I hope Andrea will come up with some tests for you guys to provide
> more information, so he does eventually understand the cause(s). I
> don't think we can in good faith claim this is a GCC bug before we
> understand the problem better.
Fair enough.
> Meanwhile, I'd like to consider a PROBLEMS entry about this, if that's
> needed. Do I understand correctly that -fno-optimize-sibling-calls is
> needed for successful building of Emacs 29.0.92 using MinGW64 GCC 13.1?
I'm not tracking 29 branch closely, but from my brief testing:
• Emacs builds when running
$ ./configure --with-native-compilation && make
on the pretest tarball from
https://alpha.gnu.org/gnu/emacs/pretest/emacs-29.0.92.tar.xz
• Emacs doesn't build out of local git repo when running
$ git switch emacs-29
$ git clean -fdx
$ ./autogen.sh
$ ./configure --with-native-compilation && make
• Emacs builds out of local git repo when running
$ git switch emacs-29
$ git clean -fdx
$ ./autogen.sh
$ CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls' \
./configure --with-native-compilation && make
> If so, I think we should have this in PROBLEMS.
If others can reproduce my experience, then it probably makes sense.
> Also, why are you using -O3? That is not recommended when building
> Emacs.
I wasn't aware of that. Can you elaborate why -O3 isn't recommended?
Or any pointer where I can read about it?
> (But I understand that -foptimize-sibling-calls is in -O2, not just in
> -O3, and so -fno-optimize-sibling-calls is needed even if using -O2,
> right?)
Correct, this is also what I read from this page and my experience so
far[1].
Best, Arash
Footnotes:
[1] https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 23 Jun 2023 12:16:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: Andrea Corallo <acorallo <at> gnu.org>, cyril.arnould <at> outlook.com,
> 63365 <at> debbugs.gnu.org, svraka.andras <at> gmail.com
> Date: Fri, 23 Jun 2023 13:41:10 +0200
>
> I'm not tracking 29 branch closely, but from my brief testing:
>
> • Emacs builds when running
> $ ./configure --with-native-compilation && make
> on the pretest tarball from
> https://alpha.gnu.org/gnu/emacs/pretest/emacs-29.0.92.tar.xz
>
> • Emacs doesn't build out of local git repo when running
> $ git switch emacs-29
> $ git clean -fdx
> $ ./autogen.sh
> $ ./configure --with-native-compilation && make
This might mean that the problem happens when byte-compiling *.el
files -- in the tarball all the *.elc files are already present. What
happens if you remove the *.elc files from the release tarball, and
then try building it?
> > Also, why are you using -O3? That is not recommended when building
> > Emacs.
>
> I wasn't aware of that. Can you elaborate why -O3 isn't recommended?
In a nutshell, it bloats the code (due to excessive inlining), with no
real effect on speed. The inner loops in Emacs are very large, and
thus the techniques used by -O3 to speed up code (loop unrolling etc.)
don't really work. Moreover, they could make things worse because the
larger loops might no longer fit into the L1 cache of the CPU.
The -O3 is well suited to speed up relatively simple algorithms with
tight loops. Emacs has very few of those, in the places that matter
for observable performance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 23 Jun 2023 12:52:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> This might mean that the problem happens when byte-compiling *.el
> files -- in the tarball all the *.elc files are already present. What
> happens if you remove the *.elc files from the release tarball, and
> then try building it?
This is indeed the case: Removing the *.elc after unpacking the tarball
and running
./configure --with-native-compilation && make
doesn't build -- I will try ./configure --without-native-compilation
later.
> In a nutshell, it bloats the code (due to excessive inlining), with no
> real effect on speed. The inner loops in Emacs are very large, and
> thus the techniques used by -O3 to speed up code (loop unrolling etc.)
> don't really work. Moreover, they could make things worse because the
> larger loops might no longer fit into the L1 cache of the CPU.
>
> The -O3 is well suited to speed up relatively simple algorithms with
> tight loops. Emacs has very few of those, in the places that matter
> for observable performance.
Thanks! I will go with -O2 in future.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 24 Jun 2023 09:18:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 63365 <at> debbugs.gnu.org (full text, mbox):
On 2023-06-23T15:15 Fri, Eli Zaretskii wrote:
>> From: Arash Esbati <arash <at> gnu.org>
>> Cc: Andrea Corallo <acorallo <at> gnu.org>, cyril.arnould <at> outlook.com,
>> 63365 <at> debbugs.gnu.org, svraka.andras <at> gmail.com
>> Date: Fri, 23 Jun 2023 13:41:10 +0200
>>
>> > Also, why are you using -O3? That is not recommended when building
>> > Emacs.
>>
>> I wasn't aware of that. Can you elaborate why -O3 isn't recommended?
>
> In a nutshell, it bloats the code (due to excessive inlining), with no
> real effect on speed. The inner loops in Emacs are very large, and
> thus the techniques used by -O3 to speed up code (loop unrolling etc.)
> don't really work. Moreover, they could make things worse because the
> larger loops might no longer fit into the L1 cache of the CPU.
>
> The -O3 is well suited to speed up relatively simple algorithms with
> tight loops. Emacs has very few of those, in the places that matter
> for observable performance.
Interesting.
This recommendation and the explanation are worth documenting somewhere.
Shouldn't a new bug be opened on documenting the GCC -O3 recommendation?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 24 Jun 2023 09:22:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Deus Max <deusmax <at> gmx.com>
> Cc: Arash Esbati <arash <at> gnu.org>, 63365 <at> debbugs.gnu.org, acorallo <at> gnu.org,
> svraka.andras <at> gmail.com, cyril.arnould <at> outlook.com
> Date: Sat, 24 Jun 2023 12:17:11 +0300
>
> On 2023-06-23T15:15 Fri, Eli Zaretskii wrote:
>
> >> From: Arash Esbati <arash <at> gnu.org>
> >> Cc: Andrea Corallo <acorallo <at> gnu.org>, cyril.arnould <at> outlook.com,
> >> 63365 <at> debbugs.gnu.org, svraka.andras <at> gmail.com
> >> Date: Fri, 23 Jun 2023 13:41:10 +0200
> >>
> >> > Also, why are you using -O3? That is not recommended when building
> >> > Emacs.
> >>
> >> I wasn't aware of that. Can you elaborate why -O3 isn't recommended?
> >
> > In a nutshell, it bloats the code (due to excessive inlining), with no
> > real effect on speed. The inner loops in Emacs are very large, and
> > thus the techniques used by -O3 to speed up code (loop unrolling etc.)
> > don't really work. Moreover, they could make things worse because the
> > larger loops might no longer fit into the L1 cache of the CPU.
> >
> > The -O3 is well suited to speed up relatively simple algorithms with
> > tight loops. Emacs has very few of those, in the places that matter
> > for observable performance.
>
> Interesting.
> This recommendation and the explanation are worth documenting somewhere.
> Shouldn't a new bug be opened on documenting the GCC -O3 recommendation?
I don't think it's our business to document this. The default build
procedure correctly uses -O2. People who use non-default compilation
switches should know what they are doing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 24 Jun 2023 14:42:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 63365 <at> debbugs.gnu.org (full text, mbox):
On 2023-06-24T12:21 Sat, Eli Zaretskii wrote:
>> From: Deus Max <deusmax <at> gmx.com>
>> Cc: Arash Esbati <arash <at> gnu.org>, 63365 <at> debbugs.gnu.org, acorallo <at> gnu.org,
>> svraka.andras <at> gmail.com, cyril.arnould <at> outlook.com
>> Date: Sat, 24 Jun 2023 12:17:11 +0300
>>
>> On 2023-06-23T15:15 Fri, Eli Zaretskii wrote:
>>
>> >> From: Arash Esbati <arash <at> gnu.org>
>> >> Cc: Andrea Corallo <acorallo <at> gnu.org>, cyril.arnould <at> outlook.com,
>> >> 63365 <at> debbugs.gnu.org, svraka.andras <at> gmail.com
>> >> Date: Fri, 23 Jun 2023 13:41:10 +0200
>> >>
>> >> > Also, why are you using -O3? That is not recommended when building
>> >> > Emacs.
>> >>
>> >> I wasn't aware of that. Can you elaborate why -O3 isn't recommended?
>> >
>> > In a nutshell, it bloats the code (due to excessive inlining), with no
>> > real effect on speed. The inner loops in Emacs are very large, and
>> > thus the techniques used by -O3 to speed up code (loop unrolling etc.)
>> > don't really work. Moreover, they could make things worse because the
>> > larger loops might no longer fit into the L1 cache of the CPU.
>> >
>> > The -O3 is well suited to speed up relatively simple algorithms with
>> > tight loops. Emacs has very few of those, in the places that matter
>> > for observable performance.
>>
>> Interesting.
>> This recommendation and the explanation are worth documenting somewhere.
>> Shouldn't a new bug be opened on documenting the GCC -O3 recommendation?
>
> I don't think it's our business to document this. The default build
> procedure correctly uses -O2. People who use non-default compilation
> switches should know what they are doing.
Then whose business is it?
The default of course is correct, also it is not intuitive that -O3 is
wrong. People who...should know what they are doing, but a little
explanation goes a long way. It also helps newcomers catch up.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 24 Jun 2023 15:06:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Deus Max <deusmax <at> gmx.com>
> Cc: Deus Max <deusmax <at> gmx.com>, arash <at> gnu.org, 63365 <at> debbugs.gnu.org,
> acorallo <at> gnu.org, svraka.andras <at> gmail.com, cyril.arnould <at> outlook.com
> Date: Sat, 24 Jun 2023 17:41:30 +0300
>
> >> Interesting.
> >> This recommendation and the explanation are worth documenting somewhere.
> >> Shouldn't a new bug be opened on documenting the GCC -O3 recommendation?
> >
> > I don't think it's our business to document this. The default build
> > procedure correctly uses -O2. People who use non-default compilation
> > switches should know what they are doing.
>
> Then whose business is it?
That of the GCC developers, of course. That's where the description
of -O3 and its practical implications belongs.
> The default of course is correct, also it is not intuitive that -O3 is
> wrong. People who...should know what they are doing, but a little
> explanation goes a long way. It also helps newcomers catch up.
Where do you suggest to put these factoids to make them even
marginally discoverable by those for whom you think they will be
useful? If they are hidden among the rest of 100K lines of the ELisp
manual, how will anyone be able to find them?
That is why each piece of documentation should be in its natural
place. When I want to know something about GCC optimization options,
I turn to the GCC manual, nowhere else.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sun, 25 Jun 2023 13:52:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Arash Esbati <arash <at> gnu.org>
>> Cc: "eliz <at> gnu.org" <eliz <at> gnu.org>, "63365 <at> debbugs.gnu.org"
>> <63365 <at> debbugs.gnu.org>, " akrl <at> sdf.org" <akrl <at> sdf.org>,
>> András Svraka
>> <svraka.andras <at> gmail.com>
>> Date: Thu, 22 Jun 2023 22:34:48 +0200
>>
>> Many thanks for digging into this. I can confirm that Emacs builds with
>> -fno-optimize-sibling-calls in CFLAGS. I have a script which (now)
>> does:
>>
>> CFLAGS='-O3 -g0 -pipe -fno-optimize-sibling-calls' \
>> ./configure ...
>>
>> and it works again.
>>
>> Now the question is: Is this considered a GCC bug and we should close
>> this report as notabug?
>
> AFAIR, last Andrea looked into this he was surprised by this finding
> and didn't understand how -foptimize-sibling-calls could cause such
> problems. I hope Andrea will come up with some tests for you guys to
> provide more information, so he does eventually understand the
> cause(s). I don't think we can in good faith claim this is a GCC bug
> before we understand the problem better.
Unfortunatelly I've trouble thinking to such a test.
Maybe someone should compare the two binaries (with and without
-foptimize-sibling-calls) to understand which compilation unit (and
which function) differs in details. Hopefully this could help us to
pinkpoint the function causing the issue? Once that is done it's more
easy to understand what the compiler is doing.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sun, 25 Jun 2023 15:42:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: Arash Esbati <arash <at> gnu.org>, cyril.arnould <at> outlook.com,
> 63365 <at> debbugs.gnu.org, svraka.andras <at> gmail.com
> Date: Sun, 25 Jun 2023 09:51:13 -0400
>
> Maybe someone should compare the two binaries (with and without
> -foptimize-sibling-calls) to understand which compilation unit (and
> which function) differs in details.
How does one compare binaries in a useful way? The Emacs binary is
AFAIR around 20MB even when stripped of all symbols.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sun, 25 Jun 2023 18:12:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: Arash Esbati <arash <at> gnu.org>, cyril.arnould <at> outlook.com,
>> 63365 <at> debbugs.gnu.org, svraka.andras <at> gmail.com
>> Date: Sun, 25 Jun 2023 09:51:13 -0400
>>
>> Maybe someone should compare the two binaries (with and without
>> -foptimize-sibling-calls) to understand which compilation unit (and
>> which function) differs in details.
>
> How does one compare binaries in a useful way? The Emacs binary is
> AFAIR around 20MB even when stripped of all symbols.
That's a good question, for elf there are specific tools for that, even
just readelf can output function sizes and that's a good starting point.
For Windows I've idea (I'm assuming Windows is not elf based).
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sun, 25 Jun 2023 18:32:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: arash <at> gnu.org, cyril.arnould <at> outlook.com, 63365 <at> debbugs.gnu.org,
> svraka.andras <at> gmail.com
> Date: Sun, 25 Jun 2023 14:11:15 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Maybe someone should compare the two binaries (with and without
> >> -foptimize-sibling-calls) to understand which compilation unit (and
> >> which function) differs in details.
> >
> > How does one compare binaries in a useful way? The Emacs binary is
> > AFAIR around 20MB even when stripped of all symbols.
>
> That's a good question, for elf there are specific tools for that, even
> just readelf can output function sizes and that's a good starting point.
>
> For Windows I've idea (I'm assuming Windows is not elf based).
No, Windows doesn't use ELF.
Maybe we should start by narrowing the problem? E.g., which Lisp
files cause the crashes, and which *.eln files, if any, are involved?
The C files more or less directly involved in byte-compilation are, I
think, eval.c, data.c, alloc.c, lread.c, bytecode.c. If we think one
of these could be involved, it would be nice to find the one(s) that
cause the problem, for example, by selectively compiling only those
with -fno-optimize-sibling-calls, then removing them one by one from
the set of files compiled like that.
The investigation if this bug is harder because the problem doesn't
happen when running Emacs under GDB, and conversion of backtrace
addresses to file names and line numbers for some reason also doesn't
work. So we need every smart idea we can come up with.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 26 Jun 2023 07:04:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: arash <at> gnu.org, cyril.arnould <at> outlook.com, 63365 <at> debbugs.gnu.org,
>> svraka.andras <at> gmail.com
>> Date: Sun, 25 Jun 2023 14:11:15 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Maybe someone should compare the two binaries (with and without
>> >> -foptimize-sibling-calls) to understand which compilation unit (and
>> >> which function) differs in details.
>> >
>> > How does one compare binaries in a useful way? The Emacs binary is
>> > AFAIR around 20MB even when stripped of all symbols.
>>
>> That's a good question, for elf there are specific tools for that, even
>> just readelf can output function sizes and that's a good starting point.
>>
>> For Windows I've idea (I'm assuming Windows is not elf based).
>
> No, Windows doesn't use ELF.
>
> Maybe we should start by narrowing the problem? E.g., which Lisp
> files cause the crashes, and which *.eln files, if any, are involved?
>
> The C files more or less directly involved in byte-compilation are, I
> think, eval.c, data.c, alloc.c, lread.c, bytecode.c. If we think one
> of these could be involved, it would be nice to find the one(s) that
> cause the problem, for example, by selectively compiling only those
> with -fno-optimize-sibling-calls, then removing them one by one from
> the set of files compiled like that.
That would be a good starting point already, I'd suggest to add comp.c
to the investigated set as well.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Mon, 26 Jun 2023 22:05:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> The C files more or less directly involved in byte-compilation are, I
>> think, eval.c, data.c, alloc.c, lread.c, bytecode.c. If we think one
>> of these could be involved, it would be nice to find the one(s) that
>> cause the problem, for example, by selectively compiling only those
>> with -fno-optimize-sibling-calls, then removing them one by one from
>> the set of files compiled like that.
>
> That would be a good starting point already, I'd suggest to add comp.c
> to the investigated set as well.
I can take a look into this, but I'm unsure as to how exactly; I'm still
very new to the GNU Autotools. AFAIU, this would be done using
per-target Automake variables but there's no Makefile.am...
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 27 Jun 2023 02:30:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Cyril Arnould <cyril.arnould <at> outlook.com>
> CC: "eliz <at> gnu.org" <eliz <at> gnu.org>, András Svraka
> <svraka.andras <at> gmail.com>, Arash Esbati <arash <at> gnu.org>,
> "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>
> Date: Mon, 26 Jun 2023 22:04:19 +0000
>
> >> The C files more or less directly involved in byte-compilation are, I
> >> think, eval.c, data.c, alloc.c, lread.c, bytecode.c. If we think one
> >> of these could be involved, it would be nice to find the one(s) that
> >> cause the problem, for example, by selectively compiling only those
> >> with -fno-optimize-sibling-calls, then removing them one by one from
> >> the set of files compiled like that.
> >
> > That would be a good starting point already, I'd suggest to add comp.c
> > to the investigated set as well.
>
> I can take a look into this, but I'm unsure as to how exactly; I'm still
> very new to the GNU Autotools. AFAIU, this would be done using
> per-target Automake variables but there's no Makefile.am...
No, that would be a waste of your time. It is much easier to do this
by hand. To compile, say, lread.c, do this:
$ cd src
$ make lread.o -W lread.c CFLAGS='-O2 -fno-optimize-sibling-calls'
$ make
The last "make command will produce an emacs.exe binary where lread.c
is compiled without the problematic optimization.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 27 Jun 2023 19:29:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> No, that would be a waste of your time. It is much easier to do this
> by hand. To compile, say, lread.c, do this:
>
> $ cd src
> $ make lread.o -W lread.c CFLAGS='-O2 -fno-optimize-sibling-calls'
> $ make
>
> The last "make command will produce an emacs.exe binary where lread.c
> is compiled without the problematic optimization.
I see, thanks. Is there a reason you left out the -g3 and -gdwarf-2
switches? To be sure, I've tried it with and without those, but I got
similar results so far: all of the combinations I've tried are
failing. I'm trying to widen the search to see if I can figure out which
file is the culprit.
> Maybe we should start by narrowing the problem? E.g., which Lisp
> files cause the crashes, and which *.eln files, if any, are involved?
From the tests I've run it seems to me that there is absolutely no
consistency with which lisp files cause the crashes. Each of the builds
resulted in different lisp files failing. Now, when I run the make
command again after a failed attempt, the *same* lisp files will keep
failing to build over and over. However, I also noticed that if I run
the exact same build commands again from a clean checkout, different
lisp files will fail the second time around. Is it normal that there are
run-to-run variations with GCC?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 27 Jun 2023 20:23:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>> No, that would be a waste of your time. It is much easier to do this
>
>> by hand. To compile, say, lread.c, do this:
>
>>
>
>> $ cd src
>
>> $ make lread.o -W lread.c CFLAGS='-O2 -fno-optimize-sibling-calls'
>
>> $ make
>
>>
>
>> The last "make command will produce an emacs.exe binary where lread.c
>
>> is compiled without the problematic optimization.
>
>
>
> I see, thanks. Is there a reason you left out the -g3 and -gdwarf-2
>
> switches? To be sure, I've tried it with and without those, but I got
>
> similar results so far: all of the combinations I've tried are
>
> failing. I'm trying to widen the search to see if I can figure out which
>
> file is the culprit.
>
>
>
>> Maybe we should start by narrowing the problem? E.g., which Lisp
>
>> files cause the crashes, and which *.eln files, if any, are involved?
>
>
>
> From the tests I've run it seems to me that there is absolutely no
>
> consistency with which lisp files cause the crashes. Each of the builds
>
> resulted in different lisp files failing. Now, when I run the make
>
> command again after a failed attempt, the *same* lisp files will keep
>
> failing to build over and over. However, I also noticed that if I run
>
> the exact same build commands again from a clean checkout, different
>
> lisp files will fail the second time around. Is it normal that there are
>
> run-to-run variations with GCC?
I guess is due to the parallel nature of the build (and possibly its
initial state).
Using make -j1 (or even better make bootstrap -j1) should make it
reproducible.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 28 Jun 2023 11:38:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Cyril Arnould <cyril.arnould <at> outlook.com>
> CC: "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>,
> András Svraka <svraka.andras <at> gmail.com>, Andrea Corallo
> <acorallo <at> gnu.org>, Arash Esbati <arash <at> gnu.org>
> Date: Tue, 27 Jun 2023 19:28:12 +0000
>
> > $ cd src
> > $ make lread.o -W lread.c CFLAGS='-O2 -fno-optimize-sibling-calls'
> > $ make
> >
> > The last "make command will produce an emacs.exe binary where lread.c
> > is compiled without the problematic optimization.
>
> I see, thanks. Is there a reason you left out the -g3 and -gdwarf-2
> switches?
No particular reason.
> To be sure, I've tried it with and without those, but I got
> similar results so far: all of the combinations I've tried are
> failing. I'm trying to widen the search to see if I can figure out which
> file is the culprit.
Since the problem disappears under GDB, it is probably memory-related.
So it figures that it behaves like a classic heisenbug.
Unfortunately, it means more combinations to try and more time to
waste...
> >From the tests I've run it seems to me that there is absolutely no
> consistency with which lisp files cause the crashes. Each of the builds
> resulted in different lisp files failing. Now, when I run the make
> command again after a failed attempt, the *same* lisp files will keep
> failing to build over and over. However, I also noticed that if I run
> the exact same build commands again from a clean checkout, different
> lisp files will fail the second time around. Is it normal that there are
> run-to-run variations with GCC?
See above: I'm not surprised. Especially since MinGW64 uses ASLR.
However, using sequential builds, as suggested by Andrea, could
perhaps help. I'd also consider building with -Wl,--disable-dynamicbase
for example like this (when you run Make in the src directory):
make LD_SWITCH_SYSTEM='-Wl,--disable-dynamicbase'
Maybe this will make the bug less unpredictable, who knows?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 28 Jun 2023 23:18:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ok, I think I got it; it's src/thread.c. The following build succeeds:
git clean -xdf
git checkout emacs-29.0.92
./autogen.sh
./configure --with-native-compilation
cd src
make temacs.exe
make thread.o -W thread.c CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls'
cd ..
make
I first compile temacs.exe with CFLAGS at default and then rebuild
thread.c with -fno-optimize-sibling-calls. This way thread.c should be
the only file built with the flag. Conversely, compiling with
-fno-optimiize-sibling-calls everywhere *but* thread.c fails:
git clean -xdf
git checkout emacs-29.0.92
./autogen.sh
./configure --with-native-compilation
cd src
make temacs.exe CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls'
make thread.o -W thread.c
cd ..
make CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls'
> Using make -j1 (or even better make bootstrap -j1) should make it
> reproducible.
> make LD_SWITCH_SYSTEM='-Wl,--disable-dynamicbase'
>
> Maybe this will make the bug less unpredictable, who knows?
Tried them, the failing lisp files still seem random.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 29 Jun 2023 05:21:01 GMT)
Full text and
rfc822 format available.
Message #191 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Cyril Arnould <cyril.arnould <at> outlook.com>
> CC: "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>
> Date: Wed, 28 Jun 2023 23:16:58 +0000
>
> Ok, I think I got it; it's src/thread.c. The following build succeeds:
>
> git clean -xdf
> git checkout emacs-29.0.92
> ./autogen.sh
> ./configure --with-native-compilation
> cd src
> make temacs.exe
> make thread.o -W thread.c CFLAGS='-g3 -O2 -gdwarf-2 -fno-optimize-sibling-calls'
> cd ..
> make
OK, so I guess the next step is to compare the code produced from
thread.c between these two compilations. Like this:
cd src
objdump -d -S thread-with.o > with.txt
objdump -d -S thread-without.o > without.txt
diff -ubBw with.txt without.txt
where the two *.o files are thread.o you get when compiling,
respectively, with and without -fno-optimize-sibling-calls option.
Then post here the two *.txt files and the diffs, and let's see where
this leads us. (I hope the two *.txt files will not be identical...)
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 29 Jun 2023 06:37:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The two are very different indeed. You can find the files including the
objects in the attachment. A lot of the differences come down to
different addresses though; I've tried to eliminate those differences by
replacing all addresses with **** in the separate files with suffix '-addr'.
[Message part 2 (text/html, inline)]
[thread-diff.tar.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 29 Jun 2023 08:22:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
> The two are very different indeed. You can find the files including the
>
> objects in the attachment. A lot of the differences come down to
>
> different addresses though; I've tried to eliminate those differences by
>
> replacing all addresses with **** in the separate files with suffix '-addr'.
Hi Cyril,
before getting into the diff of the binary given we can use objdump (I
understand it only now sorry) I suggest we compare function sizes with
objdump -t.
Also I'm assuming we are 100% sure the culprint is thread.o, given the
bug looks not very reproducible I'd repeat the test a couple of times to
be super sure we have identified the culprint.
Thanks for your time and patience
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 29 Jun 2023 09:17:01 GMT)
Full text and
rfc822 format available.
Message #200 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> before getting into the diff of the binary given we can use objdump (I
> understand it only now sorry) I suggest we compare function sizes with
> objdump -t.
I'm not sure I follow, so let me be more explicit: The attached archive
contains the thread.o files from both runs, renamed to
'thread-foptimize-sibling-calls.o' and
'thread-fno-optimize-sibling-calls.o', respectively. This is mostly in
case someone wants to generate their own dumps.
Next, there's two text files for each that were generated using 'objdump
-d -S' as Eli suggested; 'foptimize-sibling-calls.txt' and
'fno-optimize-sibling-calls.txt'. There's also a diff of the two in
'diff.txt', generated with 'diff -ubBw'.
I noticed that in the diff, quite a lot of differences simply come down
to addresses, so I edited the objdumps of both files by hand by
replacing the addresses with ****. Those files are
'fno-optimize-sibling-calls-addr.txt' and
'foptimize-sibling-calls-addr.txt'. This greatly reduced their diff,
which is provided in 'diff-addr.txt'.
Now, as for objdump -t: I've attached the dumps and diff in this mail.
> Also I'm assuming we are 100% sure the culprint is thread.o, given the
> bug looks not very reproducible I'd repeat the test a couple of times to
> be super sure we have identified the culprint.
I did run it several times, I found it by doing a binary search over the
.c files in the src folder (i.e. I compiled half the .c files with the
optimization and half of them without it, then repeated with the
succeeding half). I can't recall a single run where the build succeeded
when thread.c was compiled with -foptimize-sibling-calls. Conversely,
the build so far never failed when thread.c was compiled with
-fno-optimize-sibling-calls.
[Message part 2 (text/html, inline)]
[foptimize-sibling-calls-dumpt.txt (text/plain, attachment)]
[fno-optimize-sibling-calls-dumpt.txt (text/plain, attachment)]
[diff-dumpt.txt (text/plain, attachment)]
Forcibly Merged 63365 65727.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Thu, 21 Sep 2023 08:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 Jan 2024 13:12:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 11 May 2023 13:06:15 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
>
> > Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> > Date: Wed, 10 May 2023 22:08:57 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > > Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> > > Date: Wed, 10 May 2023 19:54:06 +0300
> > > From: Eli Zaretskii <eliz <at> gnu.org>
> > >
> > > Maybe it's a bug in your addr2line, then. It works perfectly here,
> > > FWIW.
> > >
> > > Can you make the unstripped emacs.exe available for download
> > > somewhere, along with the emacs_backtrace.txt produced by that same
> > > binary? I'd like to take a look.
> >
> > Hmm... looking at the files you sent, I'm beginning to think something
> > is wrong with generating backtraces on MS-Windows in the 64-bit
> > builds. Maybe it has to do with ASLR, or maybe the code which
> > produces the backtrace is wrong in 64-bit executables.
>
> Actually, I take this back: the addresses in emacs_backtrace.txt seem
> reasonable, similar to addresses shown in GDB backtraces from a 64-bit
> Windows build we have on the bug tracker.
>
> So the suspicion goes back to addr2line, although I see the same
> problem with my version, which I built myself and which works
> flawlessly with the 32-bit MinGW build of Emacs.
This conclusion was incorrect. There's nothing wrong with addr2line;
the reason for the problem _was_ ASLR. addr2line interprets the
addresses in emacs_backtrace.txt relative to the base address of the
program image as recorded in the PE header of the executable file. It
cannot do anything else, since it doesn't have a live program to work
with (unlike when running Emacs under GDB). But ASLR causes programs
be loaded at base addresses that are randomized from run to run, and
thus are usually different from what is recorded in the PE header. So
for this to work on modern versions of Windows, Emacs must correct the
addresses it writes to emacs_backtrace.txt, so as to make them match
the situation where Emacs is loaded at the fixed base address recorded
in the header.
I recently upgraded my main development machine, and, as luck would
have it, had crashes during the build, so I could study the problem
and fix it. It should now be fixed on the master branch. I could
only test the solution in a 32-bit MinGW build, so please try testing
it in the 64-bit build when you have a crash on your hands.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 Jan 2024 18:26:02 GMT)
Full text and
rfc822 format available.
Message #208 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I recently upgraded my main development machine, and, as luck would
> have it, had crashes during the build, so I could study the problem
> and fix it. It should now be fixed on the master branch. I could
> only test the solution in a 32-bit MinGW build, so please try testing
> it in the 64-bit build when you have a crash on your hands.
I can confirm that Emacs now builds on Win10 64-bit with MSYS2/MINGW64
without '-fno-optimize-sibling-calls'. This is with:
gcc.exe (Rev3, Built by MSYS2 project) 13.2.0
and
CFLAGS='-O2 -g0 -pipe'
and --with-native-compilation. Do you need another confirmation?
Otherwise I can close this bug. Thanks for fixing this.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 Jan 2024 19:00:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Fri, 26 Jan 2024 19:24:50 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I recently upgraded my main development machine, and, as luck would
> > have it, had crashes during the build, so I could study the problem
> > and fix it. It should now be fixed on the master branch. I could
> > only test the solution in a 32-bit MinGW build, so please try testing
> > it in the 64-bit build when you have a crash on your hands.
>
> I can confirm that Emacs now builds on Win10 64-bit with MSYS2/MINGW64
> without '-fno-optimize-sibling-calls'. This is with:
>
> gcc.exe (Rev3, Built by MSYS2 project) 13.2.0
>
> and
>
> CFLAGS='-O2 -g0 -pipe'
>
> and --with-native-compilation. Do you need another confirmation?
That's good to know, but I also wanted to be sure that
emacs_backtrace.txt can now be processed with addr2line. If you have
a way of causing Emacs to crash and output emacs_backtrace.txt, please
test that. If not, this can wait until there is some crash.
> Otherwise I can close this bug. Thanks for fixing this.
Thanks.
P.S. Btw, I recommend using -g3, not -g0, as the former will produce
more useful debug info.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 26 Jan 2024 20:34:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> That's good to know, but I also wanted to be sure that
> emacs_backtrace.txt can now be processed with addr2line. If you have
> a way of causing Emacs to crash and output emacs_backtrace.txt, please
> test that. If not, this can wait until there is some crash.
Ok, I will play with this and see if I can trigger the issue again; I'll
report back.
> P.S. Btw, I recommend using -g3, not -g0, as the former will produce
> more useful debug info.
Thanks, got it. I have an aged Windows box here and tried to optimize
the build as far as possible for daily usage, and then rebuild for
specific bug reports with other flags.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Feb 2024 10:41:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Arash Esbati <arash <at> gnu.org> writes:
> Ok, I will play with this and see if I can trigger the issue again; I'll
> report back.
Here is the report. Suppose the repo is inside Z:/emacs-build-test
up-to-date with de020255a5c, I did:
$ ./autogen.sh
$ ./configure --with-native-compilation
$ make
$ addr2line -C -f -i -p -e src/emacs.exe < lisp/emacs_backtrace.txt
The results are attached. HTH.
Best, Arash
[emacs_backtrace.txt (text/plain, attachment)]
[addr2line.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Feb 2024 11:04:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Thu, 01 Feb 2024 11:39:18 +0100
>
> Arash Esbati <arash <at> gnu.org> writes:
>
> > Ok, I will play with this and see if I can trigger the issue again; I'll
> > report back.
>
> Here is the report. Suppose the repo is inside Z:/emacs-build-test
> up-to-date with de020255a5c, I did:
>
> $ ./autogen.sh
> $ ./configure --with-native-compilation
> $ make
> $ addr2line -C -f -i -p -e src/emacs.exe < lisp/emacs_backtrace.txt
Does this mean the build of the master branch still crashes for you?
I thought this was resolved long ago... Or do you work around this in
some way?
> The results are attached. HTH.
Thanks. I think this means the problem with the backtrace addresses
has been solved, indeed: the frames which are printed with file name
and function name looks reasonable. Those which remained "??" I think
are due to optimizations or something. It would be educational to see
a corresponding backtrace from GDB, if you can capture it, since we
will be able then to compare the "??" portions with what GDB knows
about them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Feb 2024 11:13:01 GMT)
Full text and
rfc822 format available.
Message #223 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Does this mean the build of the master branch still crashes for you?
> I thought this was resolved long ago... Or do you work around this in
> some way?
It did crash during this build, yes. The solution provided once was to
set '-fno-optimize-sibling-calls', and this is what I usually do and it
works:
$ CFLAGS='-O2 -fno-optimize-sibling-calls' ./configure ...
> Thanks. I think this means the problem with the backtrace addresses
> has been solved, indeed: the frames which are printed with file name
> and function name looks reasonable. Those which remained "??" I think
> are due to optimizations or something. It would be educational to see
> a corresponding backtrace from GDB, if you can capture it, since we
> will be able then to compare the "??" portions with what GDB knows
> about them.
Did you give me a recipe how to produce the backtrace from GDB?
Otherwise I'll go through this thread and look.
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 01 Feb 2024 11:28:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Arash Esbati <arash <at> gnu.org>
> Cc: 63365 <at> debbugs.gnu.org, akrl <at> sdf.org
> Date: Thu, 01 Feb 2024 12:11:25 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Does this mean the build of the master branch still crashes for you?
> > I thought this was resolved long ago... Or do you work around this in
> > some way?
>
> It did crash during this build, yes. The solution provided once was to
> set '-fno-optimize-sibling-calls', and this is what I usually do and it
> works:
>
> $ CFLAGS='-O2 -fno-optimize-sibling-calls' ./configure ...
Ah, okay. So this is still the same version of GCC/libgccjit, and
downgrading them to an older version also solves the problem?
> > Thanks. I think this means the problem with the backtrace addresses
> > has been solved, indeed: the frames which are printed with file name
> > and function name looks reasonable. Those which remained "??" I think
> > are due to optimizations or something. It would be educational to see
> > a corresponding backtrace from GDB, if you can capture it, since we
> > will be able then to compare the "??" portions with what GDB knows
> > about them.
>
> Did you give me a recipe how to produce the backtrace from GDB?
> Otherwise I'll go through this thread and look.
I don't mind giving the instructions again:
. run "make V=1"
. find the last command before the crash
. start GDB as "gdb ./emacs.exe" from the src subdirectory
. if the crashed command was run from the lisp/ subdirectory, type
at the GDB prompt "cd ../lisp"
. finally, type "run" followed by the failing command line, which
you can copy/paste from the output of "make V=1" above
This should run the failed command, and cause the crash. Then type:
(gdb) thread 1
(gdb) bt
and post here everything that command produces.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 14 May 2024 19:53:02 GMT)
Full text and
rfc822 format available.
Message #229 received at 63365 <at> debbugs.gnu.org (full text, mbox):
I believe the problem is centered around the mark_threads function (in
thread.c). I still have no idea if the issue is with emacs or GCC, but
I hope this helps narrow it down.
I found it by trying to suppress the sibling call optimization through
printf statements at the end of every function that showed differences
between the objdump files. With the additional printf calls, the
native-compilation build works together with the
-foptimize-sibling-calls flag.
After that, it was just a matter of narrowing it down. You can try it
for yourself with the following patch:
diff --git a/src/thread.c b/src/thread.c
index 040ca39511e..b522d146779 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -696,6 +696,7 @@ mark_threads_callback (void *ignore)
mark_threads (void)
{
flush_stack_call_func (mark_threads_callback, NULL);
+ printf("");
}
void
Note that by now I've moved on to emacs-29.3 on GCC 14, however it
seems that the issue is still exactly the same.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 14 May 2024 20:37:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
> I believe the problem is centered around the mark_threads function (in
> thread.c). I still have no idea if the issue is with emacs or GCC, but
> I hope this helps narrow it down.
>
> I found it by trying to suppress the sibling call optimization through
> printf statements at the end of every function that showed differences
> between the objdump files. With the additional printf calls, the
> native-compilation build works together with the
> -foptimize-sibling-calls flag.
>
> After that, it was just a matter of narrowing it down. You can try it
> for yourself with the following patch:
>
> diff --git a/src/thread.c b/src/thread.c
> index 040ca39511e..b522d146779 100644
> --- a/src/thread.c
> +++ b/src/thread.c
> @@ -696,6 +696,7 @@ mark_threads_callback (void *ignore)
> mark_threads (void)
> {
> flush_stack_call_func (mark_threads_callback, NULL);
> + printf("");
> }
>
> void
>
> Note that by now I've moved on to emacs-29.3 on GCC 14, however it
> seems that the issue is still exactly the same.
Interesting, would you mind instead of using 'printf' to try using
'__attribute__((optimize("O0")))' on the function to verify that the
issue is really an optimization?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Tue, 14 May 2024 23:30:02 GMT)
Full text and
rfc822 format available.
Message #235 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> Interesting, would you mind instead of using 'printf' to try using
> '__attribute__((optimize("O0")))' on the function to verify that the
> issue is really an optimization?
With the following, the build fails:
diff --git a/src/thread.c b/src/thread.c
index 040ca39511e..ffdcf420af0 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -692,6 +692,7 @@ mark_threads_callback (void *ignore)
}
}
+__attribute__((optimize("O0")))
void
mark_threads (void)
{
I hope this was correct? If I replace it with
'__attribute__((optimize("no-optimize-sibling-calls")))', the build
succeeds again.
I therefore tried to compile the entirety of thread.c with -O0
instead, upon which the build succeeded again. I'll try to add the
'__attribute__((optimize("O0")))' in more thread.c functions to see
which ones need it for a successful build (unless you have a better
suggestion?).
To summarize the current state:
thread.c compiled with -O2: build fails
thread.c compiled with -O2 -fno-optimize-sibling-calls: build succeeds
thread.c compiled with -O0: build succeeds
thread.c compiled with -O2 and
- mark_threads with printf: build succeeds
- mark_threads with
__attribute__((optimize("no-optimize-sibling-calls"))): build succeeds
- mark_threads with __attribute__((optimize("O0"))): build fails
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 15 May 2024 06:42:01 GMT)
Full text and
rfc822 format available.
Message #238 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>> Interesting, would you mind instead of using 'printf' to try using
>> '__attribute__((optimize("O0")))' on the function to verify that the
>> issue is really an optimization?
>
> With the following, the build fails:
>
>
> diff --git a/src/thread.c b/src/thread.c
> index 040ca39511e..ffdcf420af0 100644
> --- a/src/thread.c
> +++ b/src/thread.c
> @@ -692,6 +692,7 @@ mark_threads_callback (void *ignore)
> }
> }
>
> +__attribute__((optimize("O0")))
> void
> mark_threads (void)
> {
>
>
> I hope this was correct? If I replace it with
> '__attribute__((optimize("no-optimize-sibling-calls")))', the build
> succeeds again.
>
> I therefore tried to compile the entirety of thread.c with -O0
> instead, upon which the build succeeded again. I'll try to add the
> '__attribute__((optimize("O0")))' in more thread.c functions to see
> which ones need it for a successful build (unless you have a better
> suggestion?).
>
> To summarize the current state:
>
> thread.c compiled with -O2: build fails
> thread.c compiled with -O2 -fno-optimize-sibling-calls: build succeeds
> thread.c compiled with -O0: build succeeds
>
> thread.c compiled with -O2 and
> - mark_threads with printf: build succeeds
> - mark_threads with
> __attribute__((optimize("no-optimize-sibling-calls"))): build
> succeeds
> - mark_threads with __attribute__((optimize("O0"))): build fails
Mmmh 🧐, must say it does not make much sense to me. Are we sure these
results are reliably reproducible and we are not looking at some
statistic fluctuation of a non very reproducible issue?
Anyway if marking 'mark_threads' with
__attribute__((optimize("no-optimize-sibling-calls"))) solves the issue
in a stable way I think we should compare the assembly output of the two
functions.
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 15 May 2024 16:37:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Mmmh 🧐, must say it does not make much sense to me. Are we sure these
> results are reliably reproducible and we are not looking at some
> statistic fluctuation of a non very reproducible issue?
I understand your scepticism. However, I've ran every build 2-4 times,
and so far my reproducibility is at 100%. As in; with the same
configuration the build (as a whole) either always fails or is always
successful. It does seem random however which of the byte-compile
steps fail in the end. Maybe the -fno-optimize-sibling-calls just
makes the failure much more unlikely.
> Anyway if marking 'mark_threads' with
> __attribute__((optimize("no-optimize-sibling-calls"))) solves the issue
> in a stable way I think we should compare the assembly output of the two
> functions.
I've attached the corresponding objdump -S -d (including the original
.o files). This time I've modified thread.c so that 'mark_threads'
comes dead last. I ran the builds another 4 times each to make
sure. Moving the function in the source also moves it to the end of
the dumps, makes for easier diffing:
diff -ubBw thread.txt thread-attr-no-optimize-sibling-calls.txt
--- thread.txt 2024-05-15 17:59:49.003434900 +0200
+++ thread-attr-no-optimize-sibling-calls.txt 2024-05-15
17:38:35.029292300 +0200
@@ -1,5 +1,5 @@
-../thread-last.o: file format pe-x86-64
+../thread-attr-last.o: file format pe-x86-64
Disassembly of section .text:
@@ -2305,6 +2305,7 @@
00000000000017d0 <mark_threads>:
+__attribute__((optimize("no-optimize-sibling-calls")))
void
mark_threads (void)
{
@@ -2316,50 +2317,49 @@
17d9: 57 push %rdi
17da: 56 push %rsi
17db: 53 push %rbx
- 17dc: 48 81 ec a8 00 00 00 sub $0xa8,%rsp
- 17e3: 48 8d 2c 24 lea (%rsp),%rbp
- 17e7: 0f 11 75 00 movups %xmm6,0x0(%rbp)
- 17eb: 0f 11 7d 10 movups %xmm7,0x10(%rbp)
- 17ef: 44 0f 11 45 20 movups %xmm8,0x20(%rbp)
- 17f4: 44 0f 11 4d 30 movups %xmm9,0x30(%rbp)
- 17f9: 44 0f 11 55 40 movups %xmm10,0x40(%rbp)
- 17fe: 44 0f 11 5d 50 movups %xmm11,0x50(%rbp)
- 1803: 44 0f 11 65 60 movups %xmm12,0x60(%rbp)
- 1808: 44 0f 11 6d 70 movups %xmm13,0x70(%rbp)
- 180d: 44 0f 11 b5 80 00 00 movups %xmm14,0x80(%rbp)
- 1814: 00
- 1815: 44 0f 11 bd 90 00 00 movups %xmm15,0x90(%rbp)
- 181c: 00
+ 17dc: 48 81 ec c8 00 00 00 sub $0xc8,%rsp
+ 17e3: 48 8d 6c 24 20 lea 0x20(%rsp),%rbp
+ 17e8: 0f 11 75 00 movups %xmm6,0x0(%rbp)
+ 17ec: 0f 11 7d 10 movups %xmm7,0x10(%rbp)
+ 17f0: 44 0f 11 45 20 movups %xmm8,0x20(%rbp)
+ 17f5: 44 0f 11 4d 30 movups %xmm9,0x30(%rbp)
+ 17fa: 44 0f 11 55 40 movups %xmm10,0x40(%rbp)
+ 17ff: 44 0f 11 5d 50 movups %xmm11,0x50(%rbp)
+ 1804: 44 0f 11 65 60 movups %xmm12,0x60(%rbp)
+ 1809: 44 0f 11 6d 70 movups %xmm13,0x70(%rbp)
+ 180e: 44 0f 11 b5 80 00 00 movups %xmm14,0x80(%rbp)
+ 1815: 00
+ 1816: 44 0f 11 bd 90 00 00 movups %xmm15,0x90(%rbp)
+ 181d: 00
flush_stack_call_func1 (func, arg);
- 181d: 31 d2 xor %edx,%edx
- 181f: 48 8d 0d da eb ff ff lea -0x1426(%rip),%rcx #
400 <mark_threads_callback>
+ 181e: 31 d2 xor %edx,%edx
+ 1820: 48 8d 0d d9 eb ff ff lea -0x1427(%rip),%rcx #
400 <mark_threads_callback>
+ 1827: e8 00 00 00 00 call 182c <mark_threads+0x5c>
+ 182c: 90 nop
flush_stack_call_func (mark_threads_callback, NULL);
}
- 1826: 0f 10 75 00 movups 0x0(%rbp),%xmm6
- 182a: 0f 10 7d 10 movups 0x10(%rbp),%xmm7
- 182e: 44 0f 10 45 20 movups 0x20(%rbp),%xmm8
- 1833: 44 0f 10 4d 30 movups 0x30(%rbp),%xmm9
- 1838: 44 0f 10 55 40 movups 0x40(%rbp),%xmm10
- 183d: 44 0f 10 5d 50 movups 0x50(%rbp),%xmm11
- 1842: 44 0f 10 65 60 movups 0x60(%rbp),%xmm12
- 1847: 44 0f 10 6d 70 movups 0x70(%rbp),%xmm13
- 184c: 44 0f 10 b5 80 00 00 movups 0x80(%rbp),%xmm14
- 1853: 00
- 1854: 44 0f 10 bd 90 00 00 movups 0x90(%rbp),%xmm15
- 185b: 00
- 185c: 48 81 c4 a8 00 00 00 add $0xa8,%rsp
- 1863: 5b pop %rbx
- 1864: 5e pop %rsi
- 1865: 5f pop %rdi
- 1866: 41 5c pop %r12
- 1868: 41 5d pop %r13
- 186a: 41 5e pop %r14
- 186c: 41 5f pop %r15
- 186e: 5d pop %rbp
- 186f: e9 00 00 00 00 jmp 1874 <mark_threads+0xa4>
- 1874: 90 nop
- 1875: 90 nop
- 1876: 90 nop
+ 182d: 0f 10 75 00 movups 0x0(%rbp),%xmm6
+ 1831: 0f 10 7d 10 movups 0x10(%rbp),%xmm7
+ 1835: 44 0f 10 45 20 movups 0x20(%rbp),%xmm8
+ 183a: 44 0f 10 4d 30 movups 0x30(%rbp),%xmm9
+ 183f: 44 0f 10 55 40 movups 0x40(%rbp),%xmm10
+ 1844: 44 0f 10 5d 50 movups 0x50(%rbp),%xmm11
+ 1849: 44 0f 10 65 60 movups 0x60(%rbp),%xmm12
+ 184e: 44 0f 10 6d 70 movups 0x70(%rbp),%xmm13
+ 1853: 44 0f 10 b5 80 00 00 movups 0x80(%rbp),%xmm14
+ 185a: 00
+ 185b: 44 0f 10 bd 90 00 00 movups 0x90(%rbp),%xmm15
+ 1862: 00
+ 1863: 48 81 c4 c8 00 00 00 add $0xc8,%rsp
+ 186a: 5b pop %rbx
+ 186b: 5e pop %rsi
+ 186c: 5f pop %rdi
+ 186d: 41 5c pop %r12
+ 186f: 41 5d pop %r13
+ 1871: 41 5e pop %r14
+ 1873: 41 5f pop %r15
+ 1875: 5d pop %rbp
+ 1876: c3 ret
1877: 90 nop
1878: 90 nop
1879: 90 nop
[objdump.tar.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 15 May 2024 17:10:01 GMT)
Full text and
rfc822 format available.
Message #244 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>> Mmmh 🧐, must say it does not make much sense to me. Are we sure these
>> results are reliably reproducible and we are not looking at some
>> statistic fluctuation of a non very reproducible issue?
>
> I understand your scepticism. However, I've ran every build 2-4 times,
> and so far my reproducibility is at 100%. As in; with the same
> configuration the build (as a whole) either always fails or is always
> successful. It does seem random however which of the byte-compile
> steps fail in the end. Maybe the -fno-optimize-sibling-calls just
> makes the failure much more unlikely.
I was more confused then sceptic 🙂
>> Anyway if marking 'mark_threads' with
>> __attribute__((optimize("no-optimize-sibling-calls"))) solves the issue
>> in a stable way I think we should compare the assembly output of the two
>> functions.
>
> I've attached the corresponding objdump -S -d (including the original
> .o files). This time I've modified thread.c so that 'mark_threads'
> comes dead last. I ran the builds another 4 times each to make
> sure. Moving the function in the source also moves it to the end of
> the dumps, makes for easier diffing:
Okay this is getting really interesting, one of the two versions seems
to be actually optimized for recursion (dunno why we could not see it
from the pass dump) so your theory seems confirmed! 😀
If you could also share the two preprocessed versions of thread.c would
be of great help. You should be able to do it adding to your original
GCC invokation like "-E -o thread.i".
Thanks!
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Wed, 15 May 2024 18:47:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 63365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> If you could also share the two preprocessed versions of thread.c would
> be of great help. You should be able to do it adding to your original
> GCC invokation like "-E -o thread.i".
What I ended up doing was:
cd src
make thread.o -W thread.c CFLAGS='-g3 -O2 -gdwarf-2
-Wno-error=implicit-function-declaration -E -o thread.i'
I hope this is what you were after. The addition of
'-Wno-error=implicit-function-declaration' comes from issue #70889
btw. I've also edited the "E:/Git/emacs-debug-gcc14/emacs" paths in
the thread.i files by hand so they don't show up in the diff; they
were originally compiled in two separate folders. The resulting files
are almost exactly the same:
diff -ubBw thread.i thread-attr-no-optimize-sibling-calls.i
--- thread.i 2024-05-15 20:34:08 +0000
+++ thread-attr-no-optimize-sibling-calls.i 2024-05-15 20:33:44 +0000
@@ -152355,12 +152355,13 @@
}
+__attribute__((optimize("no-optimize-sibling-calls")))
void
mark_threads (void)
{
flush_stack_call_func (mark_threads_callback,
-# 1181 "thread.c" 3 4
+# 1182 "thread.c" 3 4
((void *)0)
-# 1181 "thread.c"
+# 1182 "thread.c"
);
}
[preproc.tar.gz (application/x-gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 16 May 2024 14:02:01 GMT)
Full text and
rfc822 format available.
Message #250 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>> If you could also share the two preprocessed versions of thread.c would
>> be of great help. You should be able to do it adding to your original
>> GCC invokation like "-E -o thread.i".
>
> What I ended up doing was:
>
> cd src
> make thread.o -W thread.c CFLAGS='-g3 -O2 -gdwarf-2
> -Wno-error=implicit-function-declaration -E -o thread.i'
>
> I hope this is what you were after.
Hi Cyril,
it would be great if you could:
$ cd src
$ touch thread.c
$ make thread.o V=1
Get the exact GCC invocation and add there "-E -o thread.i". This way
we are sure we are looking at the right thing.
Thanks for your patience
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Thu, 16 May 2024 20:09:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> it would be great if you could:
>
> $ cd src
> $ touch thread.c
> $ make thread.o V=1
>
> Get the exact GCC invocation and add there "-E -o thread.i". This way
> we are sure we are looking at the right thing.
I did as you asked, but a diff with the previously sent files shows
that the new ones are identical. At least I wasn't totally wrong with
my guess :) The exact invocation was:
gcc -c -mtune=generic -DUSE_CRT_DLL=1 -I
/e/Git/emacs-debug-gcc14/emacs-attr/nt/inc -Demacs -I. -I. -I../lib
-I../lib -mtune=generic -isystem
C:/msys64/mingw64/include/librsvg-2.0 -isystem
C:/msys64/mingw64/include/gdk-pixbuf-2.0 -isystem
C:/msys64/mingw64/include/webp -DLIBDEFLATE_DLL -isystem
C:/msys64/mingw64/include/cairo -isystem
C:/msys64/mingw64/include/freetype2 -isystem
C:/msys64/mingw64/include/libpng16 -isystem
C:/msys64/mingw64/include/harfbuzz -isystem
C:/msys64/mingw64/include/glib-2.0 -isystem
C:/msys64/mingw64/lib/glib-2.0/include -isystem
C:/msys64/mingw64/include/pixman-1 -isystem
C:/msys64/mingw64/include/libxml2 -isystem
C:/msys64/mingw64/include/webp -isystem
C:/msys64/mingw64/include/harfbuzz -isystem
C:/msys64/mingw64/include/freetype2 -isystem
C:/msys64/mingw64/include/libpng16 -isystem
C:/msys64/mingw64/include/glib-2.0 -isystem
C:/msys64/mingw64/lib/glib-2.0/include -MMD -MF deps/thread.d -MP
-isystem C:/msys64/mingw64/include/p11-kit-1 -fno-common -Wall
-Warith-conversion -Wdate-time -Wdisabled-optimization
-Wdouble-promotion -Wduplicated-cond -Wextra -Wformat-signedness
-Winit-self -Winvalid-pch -Wlogical-op -Wmissing-declarations
-Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs
-Wnull-dereference -Wold-style-definition -Wopenmp-simd -Wpacked
-Wpointer-arith -Wstrict-prototypes -Wsuggest-attribute=noreturn
-Wsuggest-final-methods -Wsuggest-final-types -Wtrampolines
-Wuninitialized -Wunknown-pragmas -Wunused-macros -Wvariadic-macros
-Wvector-operation-performance -Wwrite-strings -Warray-bounds=2
-Wattribute-alias=2 -Wformat=2 -Wformat-truncation=2
-Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wuse-after-free=3
-Wvla-larger-than=4031 -Wno-missing-field-initializers
-Wno-override-init -Wno-sign-compare -Wno-type-limits
-Wno-unused-parameter -Wno-format-nonliteral -Wno-bidi-chars
-Wno-pointer-sign -g3 -O2 -gdwarf-2
-Wno-error=implicit-function-declaration thread.c -E -o thread.i
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 17 May 2024 04:45:02 GMT)
Full text and
rfc822 format available.
Message #256 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>> it would be great if you could:
>>
>> $ cd src
>> $ touch thread.c
>> $ make thread.o V=1
>>
>> Get the exact GCC invocation and add there "-E -o thread.i". This way
>> we are sure we are looking at the right thing.
>
> I did as you asked, but a diff with the previously sent files shows
> that the new ones are identical.
That's very good, is important we are sure we look at the right thing.
I'll digest them later tomorrow and report then 😃
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 17 May 2024 12:08:02 GMT)
Full text and
rfc822 format available.
Message #259 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>
>>> it would be great if you could:
>>>
>>> $ cd src
>>> $ touch thread.c
>>> $ make thread.o V=1
>>>
>>> Get the exact GCC invocation and add there "-E -o thread.i". This way
>>> we are sure we are looking at the right thing.
>>
>> I did as you asked, but a diff with the previously sent files shows
>> that the new ones are identical.
>
> That's very good, is important we are sure we look at the right thing.
> I'll digest them later tomorrow and report then 😃
Okay it's finally clear what is going on here.
In Emacs we use (in order to have all callee saved registers pushed on
the stack before entering in the garbage collector)
'__builtin_unwind_init'. Our code reduced looks like this:
test.c ====================
extern void flush_stack_call_func1 (void (*func) (void *arg), void *arg);
extern void mark_threads (void);
extern void
mark_threads_callback (void *ignore);
static inline void
flush_stack_call_func (void (*func) (void *arg), void *arg)
{
__builtin_unwind_init ();
flush_stack_call_func1 (func, arg);
}
void
mark_threads (void)
{
flush_stack_call_func (mark_threads_callback, ((void *)0));
}
====================
We want to call 'flush_stack_call_func1' being sure that all callee
saved registers are pushed on the stack (so that the GC can scan the
whole stack correctly).
The idea in pseudo asm is like:
mark_threads:
[...]
push # these pushs are from 'builtin_unwind_init'
push
push
[...]
call flush_stack_call_func1
pop # these pops are from 'builtin_unwind_init'
pop
pop
ret
Sibling call optimization makes this:
mark_threads:
[...]
push
push
push
[...]
pop
pop
pop
jmp flush_stack_call_func1
Which indeed does not work for us.
I believe this is a GCC bug as the sibling call optimizer should not run
in functions making use of 'builtin_unwind_init', even if this one is
undocumented (otherwise I can't see its reason of being 🙂).
So I filed a GCC bug [1].
Despite the fact that this will or not be recognized as a bug (and in
case fixed), I think we'll have to fix this on our codebase disabling
the sibling call optimizations on the sentive function(s).
Also note, this bug is not a native-comp specifc one, it's just most
likely non triggerable on most configuration. IOW I think we see it
only on mingw+nativecomp by chance.
Thanks
Andrea
[1] <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115132>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 17 May 2024 13:04:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>, "eliz <at> gnu.org"
> <eliz <at> gnu.org>, 65727 <at> debbugs.gnu.org, Arash Esbati <arash <at> gnu.org>,
> András Svraka <svraka.andras <at> gmail.com>
> Date: Fri, 17 May 2024 08:06:56 -0400
>
> I believe this is a GCC bug as the sibling call optimizer should not run
> in functions making use of 'builtin_unwind_init', even if this one is
> undocumented (otherwise I can't see its reason of being 🙂).
>
> So I filed a GCC bug [1].
>
> Despite the fact that this will or not be recognized as a bug (and in
> case fixed), I think we'll have to fix this on our codebase disabling
> the sibling call optimizations on the sentive function(s).
Agreed. Can you install a patch along these lines?
Do we have other functions that could be sensitive to this issue?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Fri, 17 May 2024 17:32:02 GMT)
Full text and
rfc822 format available.
Message #265 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>, "eliz <at> gnu.org"
>> <eliz <at> gnu.org>, 65727 <at> debbugs.gnu.org, Arash Esbati <arash <at> gnu.org>,
>> András Svraka <svraka.andras <at> gmail.com>
>> Date: Fri, 17 May 2024 08:06:56 -0400
>>
>> I believe this is a GCC bug as the sibling call optimizer should not run
>> in functions making use of 'builtin_unwind_init', even if this one is
>> undocumented (otherwise I can't see its reason of being 🙂).
>>
>> So I filed a GCC bug [1].
>>
>> Despite the fact that this will or not be recognized as a bug (and in
>> case fixed), I think we'll have to fix this on our codebase disabling
>> the sibling call optimizations on the sentive function(s).
>
> Agreed. Can you install a patch along these lines?
Work in progress 👍
> Do we have other functions that could be sensitive to this issue?
All functions calling 'flush_stack_call_func' are impacted, but I think
I've a fix that touches only 'flush_stack_call_func'.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 18 May 2024 07:10:02 GMT)
Full text and
rfc822 format available.
Message #268 received at 63365 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo <at> gnu.org>
>>> Cc: "63365 <at> debbugs.gnu.org" <63365 <at> debbugs.gnu.org>, "eliz <at> gnu.org"
>>> <eliz <at> gnu.org>, 65727 <at> debbugs.gnu.org, Arash Esbati <arash <at> gnu.org>,
>>> András Svraka <svraka.andras <at> gmail.com>
>>> Date: Fri, 17 May 2024 08:06:56 -0400
>>>
>>> I believe this is a GCC bug as the sibling call optimizer should not run
>>> in functions making use of 'builtin_unwind_init', even if this one is
>>> undocumented (otherwise I can't see its reason of being 🙂).
>>>
>>> So I filed a GCC bug [1].
>>>
>>> Despite the fact that this will or not be recognized as a bug (and in
>>> case fixed), I think we'll have to fix this on our codebase disabling
>>> the sibling call optimizations on the sentive function(s).
>>
>> Agreed. Can you install a patch along these lines?
>
> Work in progress 👍
>
>> Do we have other functions that could be sensitive to this issue?
>
> All functions calling 'flush_stack_call_func' are impacted, but I think
> I've a fix that touches only 'flush_stack_call_func'.
Okay I've installed 19c983ddedf on master, works here for me.
Cyril could you confirm works for you as well?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63365; Package
emacs.
(Sat, 18 May 2024 09:54:02 GMT)
Full text and
rfc822 format available.
Message #271 received at 63365 <at> debbugs.gnu.org (full text, mbox):
> Cyril could you confirm works for you as well?
It does. Thank you all for sticking this one out!
Reply sent
to
Andrea Corallo <acorallo <at> gnu.org>:
You have taken responsibility.
(Sat, 18 May 2024 17:31:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Arash Esbati <arash <at> gnu.org>:
bug acknowledged by developer.
(Sat, 18 May 2024 17:31:02 GMT)
Full text and
rfc822 format available.
Message #276 received at 63365-done <at> debbugs.gnu.org (full text, mbox):
Cyril Arnould <cyril.arnould <at> outlook.com> writes:
>> Cyril could you confirm works for you as well?
>
> It does. Thank you all for sticking this one out!
Thank you, it would be not soved without you.
Closing this then.
Thanks
Andrea
PS @Eli not sure if more releases are planned on 29 and so if we want to
backport it.
Reply sent
to
Andrea Corallo <acorallo <at> gnu.org>:
You have taken responsibility.
(Sat, 18 May 2024 17:31:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
voi dfoo <void.foo <at> gmail.com>:
bug acknowledged by developer.
(Sat, 18 May 2024 17:31:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 16 Jun 2024 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 40 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.