Building for m68k-unknown-linux-gnu fails with SIGILL with no LLVM backtrace

[glaubitz]

After a longer hiatus since my build machine was unavailable, I have finally found the time to work on the m68k backend in the Rust compiler again.

I tried building a Rust compiler for m68k with ./configure --host=m68k-unknown-linux-gnu which fails with an error that I don't know how to debug since it doesn't show an LLVM backtrace:

Building stage1 library artifacts (x86_64-unknown-linux-gnu -> m68k-unknown-linux-gnu)
   Compiling compiler_builtins v0.1.105
   Compiling core v0.0.0 (/data/home/glaubitz/rust/library/core)
   Compiling libc v0.2.150
   Compiling memchr v2.5.0
   Compiling std v0.0.0 (/data/home/glaubitz/rust/library/std)
   Compiling rustc-std-workspace-core v1.99.0 (/data/home/glaubitz/rust/library/rustc-std-workspace-core)
   Compiling alloc v0.0.0 (/data/home/glaubitz/rust/library/alloc)
   Compiling cfg-if v1.0.0
   Compiling adler v1.0.2
   Compiling rustc-demangle v0.1.23
rustc exited with signal: 4 (SIGILL) (core dumped)
error: could not compile `core` (lib)

Caused by:
  process didn't exit successfully: `/data/home/glaubitz/rust/build/bootstrap/debug/rustc /data/home/glaubitz/rust/build/bootstrap/debug/rustc --crate-name core --edition=2021 library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=171 --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -Zunstable-options --check-cfg 'cfg(feature, values("debug_refcell", "panic_immediate_abort"))' -C metadata=4656c87c5d5bad9b -C extra-filename=-4656c87c5d5bad9b --out-dir /data/home/glaubitz/rust/build/x86_64-unknown-linux-gnu/stage1-std/m68k-unknown-linux-gnu/release/deps --target m68k-unknown-linux-gnu -C linker=cc -L dependency=/data/home/glaubitz/rust/build/x86_64-unknown-linux-gnu/stage1-std/m68k-unknown-linux-gnu/release/deps -L dependency=/data/home/glaubitz/rust/build/x86_64-unknown-linux-gnu/stage1-std/release/deps -Csymbol-mangling-version=legacy -Zunstable-options '--check-cfg=cfg(feature,values(any()))' -Zunstable-options '--check-cfg=cfg(bootstrap)' '--check-cfg=cfg(stdarch_intel_sde)' '--check-cfg=cfg(no_fp_fmt_parse)' '--check-cfg=cfg(no_global_oom_handling)' '--check-cfg=cfg(no_rc)' '--check-cfg=cfg(no_sync)' '--check-cfg=cfg(backtrace_in_libstd)' '--check-cfg=cfg(target_env,values("libnx"))' '--check-cfg=cfg(target_arch,values("spirv","nvptx","xtensa"))' -Zmacro-backtrace -Clink-args=-Wl,-z,origin '-Clink-args=-Wl,-rpath,$ORIGIN/../lib' -Csplit-debuginfo=off -Cprefer-dynamic -Zinline-mir -Cembed-bitcode=yes '-Zcrate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/")' -Z binary-dep-depinfo` (exit status: 254)
warning: build failed, waiting for other jobs to finish...
rustc exited with signal: 4 (SIGILL) (core dumped)
error: could not compile `compiler_builtins` (lib)

This is most likely a bug in the LLVM M68k backend, but since it's not showing an LLVM backtrace, I am not sure how to debug this.

Any hints?

CC @jrtc27 @mshockwave @0x59616e @antoyo

[bjorn3]

Can you load the code dump in a debugger and get a backtrace? cat /proc/sys/kernel/core_pattern should show the location where it is printed. Either as absolute path, path relative to the working directory of rustc or if it starts with | as the program to which it will be sent (eg abrt, systemd-coredump, ...) Once you have located the coredump you can use for example gdb -c /path/to/core and then run bt in gdb to get a backtrace.

[glaubitz]

Thanks for the pointer. In fact, /proc/sys/kernel/core_pattern contained just |/bin/false.

However, the backtrace is not very useful:

glaubitz@node54:/data/home/glaubitz/rust> gdb /data/home/glaubitz/rust/build/bootstrap/debug/rustc ./core
GNU gdb (GDB; SUSE Linux Enterprise 15) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /data/home/glaubitz/rust/build/bootstrap/debug/rustc...
[New LWP 188147]
[New LWP 188148]
[New LWP 187967]
[New LWP 188137]
[New LWP 187954]
[New LWP 188138]
Core was generated by `/data/home/glaubitz/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc --crat'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x00007f0342bc8f08 in ?? ()
[Current thread is 1 (LWP 188147)]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /data/home/glaubitz/rust/build/bootstrap/debug/rustc.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) bt
#0  0x00007f0342bc8f08 in ?? ()
#1  0x00007f0324250298 in ?? ()
#2  0x0000000000000004 in ?? ()
#3  0x00007f03240d2e28 in ?? ()
#4  0x00007f0324250298 in ?? ()
#5  0x0000000000000000 in ?? ()
(gdb)

Do I need to enable debug builds explicitly when building rustc?

[antoyo]

Did you enable the assertions in LLVM? From what I remember, LLVM can segfault when assertions are disabled.

Btw, I'm not sure what you're trying to do, but if it helps, the GCC codegen can already build the sysroot for m68k.

[glaubitz]

Did you enable the assertions in LLVM? From what I remember, LLVM can segfault when assertions are disabled.

No, I need to figure out how to enable these when building LLVM from the Rust side.

Btw, I'm not sure what you're trying to do, but if it helps, the GCC codegen can already build the sysroot for m68k.

I want to continue working on the M68k backend in LLVM.

[antoyo]

There's a key assertions that you can set to true in the [llvm] section of config.toml. Perhaps this will help.

[glaubitz]

I'm using all debug flags that ./configure --help shows.

[workingjubilee]

@glaubitz

    print('')
    print('This configure script is a thin configuration shim over the true')
    print('configuration system, `config.toml`. You can explore the comments')
    print('in `config.example.toml` next to this configure script to see')
    print('more information about what each option is. Additionally you can')
    print('pass `--set` as an argument to set arbitrary key/value pairs')
    print('in the TOML configuration if desired')
    print('')
    print('Also note that all options which take `--enable` can similarly')
    print('be passed with `--disable-foo` to forcibly disable the option')
    sys.exit(0)

In general, the configure script was designed, a long time ago now, to make Rust easy to build for people who don't want to work on the backends. For those who do, willingness to fiddle more directly with the build configuration is expected.

[glaubitz]

@glaubitz

In general, the configure script was designed, a long time ago now, to make Rust easy to build for people who don't want to work on the backends. For those who do, willingness to fiddle more directly with the build configuration is expected.

Good point. In fact, I have started fiddling with config.toml in the meantime and I also did some bisecting which showed that older versions of the Rust compiler showed the full backtrace which indicates that the problem with the M68k LLVM backend is missing floating point support (see: https://github.com/llvm/llvm-project/issues/61744).