Comment 1 Jean-Sébastien Pédron 2018-06-12 21:55:58 UTC

Hi!

I could reproduce the error on ref11-aarch64.freebsd.org. I'm trying to recreate a bootstrap, this time directly on ref11-aarch64 (instead of cross-compiling it from amd64).

I will keep you posted.

Comment 2 Jean-Sébastien Pédron 2018-06-13 09:01:09 UTC

Building a new 1.25.0 bootstrap fails too, with the same error, but earlier in the process:

    ...
    Building stage1 std artifacts (aarch64-unknown-freebsd -> aarch64-unknown-freebsd)
       ...
       Compiling core v0.0.0 (file:///home/dumbbell/Projects/rust/rust/src/libcore)
       ...
    Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
    error: Could not compile `core`.

Here is the backtrace:

    (lldb) bt
    * thread #1, name = 'rustc', stop reason = signal SIGABRT
        frame #0: 0x0000000040582648 libc.so.7`__sys_thr_kill + 8
        frame #1: 0x0000000040582614 libc.so.7`__raise(s=6) at raise.c:52
        frame #2: 0x0000000040582588 libc.so.7`abort at abort.c:65
        frame #3: 0x00000000426f40f4 libthr.so.3`_thread_exitf(fname=<unavailable>, lineno=<unavailable>, fmt=<unavailable>) at thr_exit.c:193
        frame #4: 0x00000000426ee218 libthr.so.3`mutex_lock_common [inlined] _mutex_enter_robust(curthread=<unavailable>) at thr_mutex.c:186
      * frame #5: 0x00000000426ee200 libthr.so.3`mutex_lock_common(m=0x0000000042e55780, abstime=<unavailable>, cvattach=false, rb_onlist=false) at thr_mutex.c:718
        frame #6: 0x00000000426ecfec libthr.so.3`__pthread_mutex_lock(mutex=0x0000000042e1f5a0) at thr_mutex.c:744
        frame #7: 0x0000000045afb138 librustc_trans-llvm.so`llvm::sys::MutexImpl::acquire(void) + 16

Here is the mutex, which is not initialized as a robust one (see m_lock.m_flags):

    (lldb) p *m
    (pthread_mutex) $12 = {
      m_lock = {
        m_owner = 0
        m_flags = 0
        m_ceilings = ([0] = 0, [1] = 0)
        m_rb_lnk = 0
        m_spare = ([0] = 0, [1] = 0)
      }

But curthread->inact_mtx is non-zero:

    (lldb) p *curthread                                                                                                     
    (pthread) $13 = {
      ...
      inact_mtx = 1707143216                                           
      ...
    }

The assertion is verified before checking if the mutex is a robust one:

    int
    _mutex_enter_robust(struct pthread *curthread, struct pthread_mutex *m)
    {
    
    #if defined(_PTHREADS_INVARIANTS)
    	if (__predict_false(curthread->inact_mtx != 0))
    		PANIC("inact_mtx enter");
    #endif
    	if (!is_robust_mutex(m))
    		return (0);

I'm wondering if the assertion should be moved after the check of if an application is not allowed to mix robust and non-robust mutexes.

Comment 3 Jean-Sébastien Pédron 2018-06-25 10:25:57 UTC

After talking with kib@, the assertion is correct and an application can mix robust and non-robust mutexes.

After looking at the core dump, he believes this is a memory corruption affecting the `struct thread` or the tcb itself.

I looked this week-end at aarch64-specific or FreeBSD-specific parts of Rust and found out that on FreeBSD, `c_char` is defined as a signed char (i8) (i.e. what the implicit sign of a `char` is) on all architectures. However, ARM and AArch64 are are using unsigned chars implicitely. This is correctly represented in Rust for all OSes, but not FreeBSD.

I'm testing a patch currently.

Comment 4 Jan Beich 2018-07-01 14:17:50 UTC

If you plan to land aarch64 fix together with 1.27 update, please, tag the commit with "MFH: 2018Q3". /latest package set has a lot of churn, and in the past thunderx1 frequently crashed before completing the build.

Comment 5 Jean-Sébastien Pédron 2018-07-18 21:16:17 UTC

Here is an update as I could spend some time tonight on this issue.

The patch about `c_char` sign didn't fix the current crash of the compiler.

However what I found is that rustc seems to work on FreeBSD 11.0, but not on FreeBSD 11.1 (I didn't test FreeBSD 11.2).

So far, I was building the bootstrap compiler on FreeBSD 11.1/amd64 using cross-compilation and a FreeBSD 11.0/aarch64 userland. When I noticed that today, I updated the aarch64 userland to FreeBSD 11.1.

I'm testing the bootstrap compiler on a FreeBSD 11.2 jail. The initial bootstrap compiler (built with 11.0 userland) was able to build a stage1 compiler which crashed. The new bootstrap compiler (built with 11.1 userland) crashes right away when building Rust 1.27.0. So there must be something in FreeBSD 11.1 which changed compared to 11.0 and Rust doesn't like it anymore.

I'm going to look at the release notes of FreeBSD 11.1.

Comment 6 commit-hook 2018-07-19 20:58:02 UTC

A commit references this bug:

Author: dumbbell
Date: Thu Jul 19 20:57:13 UTC 2018
New revision: 474978
URL: https://svnweb.freebsd.org/changeset/ports/474978

Log:
  lang/rust: Update to 1.27.1

  Release notes:
  * https://blog.rust-lang.org/2018/06/21/Rust-1.27.html
  * https://blog.rust-lang.org/2018/07/10/Rust-1.27.1.html

  Rust is marked as broken on aarch64. The reason is the bootstrap
  compiler crashes currently. See PR 228892 which tracks the issue.

  A patch for aarch64 is still included. It fixes the sign for unqualified
  C char. This patch still needs to be upstream, but for that, the
  compiler needs to work again first.

  PR:		228892

Changes:
  head/lang/rust/Makefile
  head/lang/rust/distinfo
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_dragonfly_mod.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_freebsd_aarch64.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_freebsd_x86.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_freebsd_x86__64.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_mod.rs
  head/lang/rust/files/patch-src_librustc__back_target_i686__unknown__freebsd.rs
  head/lang/rust/files/patch-src_librustc__target_spec_i686__unknown__freebsd.rs
  head/lang/rust/files/patch-src_libstd_os_raw_mod.rs
  head/lang/rust/files/patch-src_libstd_sys_unix_stack__overflow.rs
  head/lang/rust/files/patch-src_llvm_utils_llvm-build_llvmbuild_main.py
  head/lang/rust/files/patch-src_vendor_libc_src_unix_bsd_freebsdlike_dragonfly_mod.rs
  head/lang/rust/files/patch-src_vendor_libc_src_unix_bsd_freebsdlike_freebsd_aarch64.rs
  head/lang/rust/files/patch-src_vendor_libc_src_unix_bsd_freebsdlike_freebsd_x86.rs
  head/lang/rust/files/patch-src_vendor_libc_src_unix_bsd_freebsdlike_freebsd_x86__64.rs
  head/lang/rust/files/patch-src_vendor_libc_src_unix_bsd_freebsdlike_mod.rs

Comment 7 Jean-Sébastien Pédron 2018-07-19 21:12:36 UTC

Nothing caught my eye in the 11.1 release notes. Now trying to debug the bootstrap compiler outside of the Rust build system.

Apparently, the crash I get is not the same as the one initially reported in this PR, though we still see the assertion message from libthr.

I'm trying to compile the following Rust file:

    fn main() {}

Here is the backtrace wile compiling it with the bootstrap compiler:

    dumbbell@ref11-aarch64:~/Projects/rust/examples % lldb ../bootstraps/2018-05-10/bin/rustc noop.rs 
    (lldb) target create "../bootstraps/2018-05-10/bin/rustc"
    Current executable set to '../bootstraps/2018-05-10/bin/rustc' (aarch64).
    (lldb) settings set -- target.run-args  "noop.rs"

    (lldb) r
    Process 69867 launching
    Process 69867 launched: '../bootstraps/2018-05-10/bin/rustc' (aarch64)
    Process 69867 stopped
    * thread #5, name = 'rustc', stop reason = signal SIGSEGV: invalid address (fault address: 0x600000001)
        frame #0: 0x000000004264c014 libthr.so.3`mutex_lock_common [inlined] enqueue_mutex at thr_mutex.c:525

    (lldb) bt
    * thread #5, name = 'rustc', stop reason = signal SIGSEGV: invalid address (fault address: 0x600000001)
      * frame #0: 0x000000004264c014 libthr.so.3`mutex_lock_common [inlined] enqueue_mutex at thr_mutex.c:525
        frame #1: 0x000000004264bfec libthr.so.3`mutex_lock_common [inlined] mutex_lock_sleep(curthread=<unavailable>, m=<unavailable>, abstime=<unavailable>) at thr_mutex.c:699
        frame #2: 0x000000004264bfec libthr.so.3`mutex_lock_common(m=0x0000000042c402a0, abstime=<unavailable>, cvattach=false, rb_onlist=false) at thr_mutex.c:725
        frame #3: 0x000000004264afec libthr.so.3`__pthread_mutex_lock(mutex=0x0000000042a2ef10) at thr_mutex.c:744
        frame #4: 0x000000004058b02c libc.so.7`__je_arena_malloc_large [inlined] __je_malloc_mutex_lock at mutex.h:92
        frame #5: 0x000000004058b020 libc.so.7`__je_arena_malloc_large(tsdn=0x00000000429f4010, arena=0x0000000042a2ef00, binind=45, zero=false) at jemalloc_arena.c:2600
        frame #6: 0x00000000405939e4 libc.so.7`__malloc [inlined] __je_arena_malloc(tsdn=<unavailable>, size=<unavailable>, zero=false, tcache=<unavailable>, slow_path=false) at arena.h:1354
        frame #7: 0x00000000405939bc libc.so.7`__malloc [inlined] __je_iallocztm(size=<unavailable>, zero=false, tcache=<unavailable>, is_metadata=false, slow_path=false) at jemalloc_internal.h:964
        frame #8: 0x00000000405939bc libc.so.7`__malloc [inlined] __je_ialloc at jemalloc_internal.h:976
        frame #9: 0x0000000040593978 libc.so.7`__malloc [inlined] ialloc_body(slow_path=false) at jemalloc_jemalloc.c:1524
        frame #10: 0x0000000040593978 libc.so.7`__malloc(size=<unavailable>) at jemalloc_jemalloc.c:1563
        frame #11: 0x000000004296f2c8 libc++.so.1`operator new(size=79704) at new.cpp:74
        frame #12: 0x00000000440213dc librustc_trans-llvm.so`llvm::AArch64TargetMachine::getSubtargetImpl(llvm::Function const&) const + 720
        frame #13: 0x0000000044274588 librustc_trans-llvm.so`(anonymous namespace)::AtomicExpand::runOnFunction(llvm::Function&) + 112
        frame #14: 0x0000000044a8bbcc librustc_trans-llvm.so`llvm::FPPassManager::runOnFunction(llvm::Function&) + 456
        frame #15: 0x0000000044a8bdd0 librustc_trans-llvm.so`llvm::FPPassManager::runOnModule(llvm::Module&) + 60
        frame #16: 0x0000000044a8c20c librustc_trans-llvm.so`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 784
        frame #17: 0x00000000436a3574 librustc_trans-llvm.so`LLVMRustWriteOutputFile + 428
        frame #18: 0x000000004359015c librustc_trans-llvm.so`_ZN11rustc_trans4back5write17write_output_file17he2d47695fa51eb67E.llvm.2088233791934217899 + 108
        frame #19: 0x0000000043673918 librustc_trans-llvm.so`_ZN11rustc_trans4back5write7codegen28_$u7b$$u7b$closure$u7d$$u7d$17h0bfb7f0f7db937c3E.llvm.1714480858746125103 + 712
        frame #20: 0x000000004366f32c librustc_trans-llvm.so`rustc::util::common::time_ext::h59e6def0448b4c90 + 88
        frame #21: 0x0000000043591c34 librustc_trans-llvm.so`rustc_trans::back::write::codegen::hff499753e1147e27 + 1832
        frame #22: 0x00000000435982a8 librustc_trans-llvm.so`rustc_trans::back::write::execute_work_item::h46fed978e68d4d78 + 3628
        frame #23: 0x0000000043661020 librustc_trans-llvm.so`std::sys_common::backtrace::__rust_begin_short_backtrace::hcfb51f1d1e68aaef + 388
        frame #24: 0x000000004359def0 librustc_trans-llvm.so`_ZN3std9panicking3try7do_call17h1d0ead4649d0f7d6E.llvm.16125824521456340837 + 44
        frame #25: 0x000000004044858c libstd-c9bbf7be046ddc36.so`__rust_maybe_catch_panic at lib.rs:102
        frame #26: 0x0000000043668cec librustc_trans-llvm.so`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h7f62517c59013ea7 + 128
        frame #27: 0x000000004043b268 libstd-c9bbf7be046ddc36.so`std::sys_common::thread::start_thread::h882983c816e4e64c [inlined] _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hb2aa8e68c9d7b094 at boxed.rs:794
        frame #28: 0x000000004043b260 libstd-c9bbf7be046ddc36.so`std::sys_common::thread::start_thread::h882983c816e4e64c at thread.rs:24
        frame #29: 0x000000004040fc58 libstd-c9bbf7be046ddc36.so`std::sys::unix::thread::Thread::new::thread_start::h333bf7be313970be at thread.rs:90
        frame #30: 0x0000000042643480 libthr.so.3`thread_start(curthread=0x0000000049e28000) at thr_create.c:289
        frame #31: 0x000000004264302c libthr.so.3`_pthread_create(thread=0x0000ffffbedfa780, attr=<unavailable>, start_routine=<unavailable>, arg=<unavailable>) at thr_create.c:185
        frame #32: 0x000000004040fa2c libstd-c9bbf7be046ddc36.so`std::sys::unix::thread::Thread::new::h691b9cdf1a9efe36 at thread.rs:80
        frame #33: 0x000000004366148c librustc_trans-llvm.so`std::thread::spawn::h69ef4d768da1fa54 + 316
        frame #34: 0x000000004365ffb8 librustc_trans-llvm.so`std::sys_common::backtrace::__rust_begin_short_backtrace::h3a9d3f28568d1f2e + 6312
        frame #35: 0x000000004359dea4 librustc_trans-llvm.so`_ZN3std9panicking3try7do_call17h03b407a1d23e13f6E.llvm.16125824521456340837 + 48
        frame #36: 0x000000004044858c libstd-c9bbf7be046ddc36.so`__rust_maybe_catch_panic at lib.rs:102
        frame #37: 0x0000000043668e90 librustc_trans-llvm.so`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::ha267216dc1e15909 + 136
        frame #38: 0x000000004043b268 libstd-c9bbf7be046ddc36.so`std::sys_common::thread::start_thread::h882983c816e4e64c [inlined] _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hb2aa8e68c9d7b094 at boxed.rs:794
        frame #39: 0x000000004043b260 libstd-c9bbf7be046ddc36.so`std::sys_common::thread::start_thread::h882983c816e4e64c at thread.rs:24
        frame #40: 0x000000004040fc58 libstd-c9bbf7be046ddc36.so`std::sys::unix::thread::Thread::new::thread_start::h333bf7be313970be at thread.rs:90
        frame #41: 0x0000000042643480 libthr.so.3`thread_start(curthread=0x000000004980f300) at thr_create.c:289
        frame #42: 0x000000004264302c libthr.so.3`_pthread_create(thread=0x0000ffffbfff1900, attr=<unavailable>, start_routine=<unavailable>, arg=<unavailable>) at thr_create.c:185
        frame #43: 0x0000ffffbfff4450

Unfortunately, while trying to get basic informations from this backtrace, like printing variables, lldb segfault too :(

Comment 8 Jean-Sébastien Pédron 2018-07-19 22:23:36 UTC

Here is another inconsistency between a constant defined in FreeBSD and Rust:

PTHREAD_STACK_MIN is define to 2048 for i386 and amd64 on FreeBSD and this is the value used globally in Rust for all FreeBSD architectures. However, aarch64 uses a PTHREAD_STACK_MIN of 4096.

I'm trying a quick patch now with the value correct for aarch64.

Comment 9 Jean-Sébastien Pédron 2018-07-21 15:13:31 UTC

Fixing the value of PTHREAD_STACK_MIN and SIGSTKSZ for aarch64 did not fix the overall crash.

The bootstrap compiler still segfaults while trying to acquire a mutex because the `struct thread` is just garbage.

I will continue to chase inconsistencies in the aarch64 port.

I found an old rust package (1.22.1_2) on one of my boxes — still works on newest current (1200081) — I can build ripgrep, fd and bingrep, at least. So it's probably not anything in the kernel…

Comment 11 Mikael Urankar 2018-10-24 19:58:25 UTC

Created attachment 198598 [details]
patch

I'm testing these bootstrap files and the attached patch, it seems to work on a recent -current:

http://mikael.urankar.free.fr/FreeBSD/aarch64/cargo-0.30.0-aarch64-unknown-freebsd.tar.gz
http://mikael.urankar.free.fr/FreeBSD/aarch64/rust-std-1.29.2-aarch64-unknown-freebsd.tar.gz
http://mikael.urankar.free.fr/FreeBSD/aarch64/rustc-1.29.2-aarch64-unknown-freebsd.tar.gz

I had to disable LLVM_ENABLE_BACKTRACES in src/llvm/CMakeLists.txt (llvm crashed with this assertion: assert(PrettyStackTraceHead == this && "Pretty stack trace entry destruction is out of order")). I don't know why and I don't plan to debug it. It's not in the attached patch.

(In reply to mikael.urankar from comment #11)
woah, great news! How did you build the bootstraps? Cross-compiling from amd64?

Comment 13 Mikael Urankar 2018-10-25 13:13:08 UTC

(In reply to Greg V from comment #12)
I natively compiled them.
I have the same problem described by Jean-Sébastien with the cross-compiled binary (from amd64). I tried to debug the problem by recompiling some base lib with debug symbols (libc, libc++ and rtld-elf). It turns out that rustc doesn't crash with the debug version of rtld-elf. And the native version doesn't crash at all with the optimized version of rtld-elf...

(In reply to mikael.urankar from comment #13)
Trying to build the port with these bootstraps — crashes when building compiler_builtins:

* thread #1, name = 'rustc', stop reason = signal SIGSEGV
  * frame #0: 0x00000000405fe18c libc.so.7`idalloctm [inlined] extent_szind_get_maybe_invalid(extent=0x0000000000000000) at extent_inlines.h:54
    frame #1: 0x00000000405fe18c libc.so.7`idalloctm [inlined] extent_szind_get(extent=0x0000000000000000) at extent_inlines.h:62
    frame #2: 0x00000000405fe18c libc.so.7`idalloctm at arena_inlines_b.h:217
    frame #3: 0x00000000405fe0ec libc.so.7`idalloctm(tsdn=0x0000000042e18020, ptr=0x00000000401778c0, tcache=0x0000000042e181e0, alloc_ctx=<unavailable>, is_internal=<unavailable>, slow_path=true) at jemalloc_internal_inlines_c.h:118
    frame #4: 0x00000000405f6b50 libc.so.7`ifree(tsd=0x0000000042e18020, ptr=0x00000000401778c0, tcache=0x0000000042e181e0, slow_path=true) at jemalloc_jemalloc.c:0
    frame #5: 0x00000000405f7304 libc.so.7`__free(ptr=0x00000000401778c0) at jemalloc_jemalloc.c:0
    frame #6: 0x0000000043e3babc librustc_codegen_llvm-llvm.so`rustc_llvm::last_error::he9977f03bcc48c0b + 124
    frame #7: 0x0000000043e3c570 librustc_codegen_llvm-llvm.so`_$LT$rustc_llvm..archive_ro..Iter$LT$$u27$a$GT$$u20$as$u20$core..iter..iterator..Iterator$GT$::next::hf73e69c8121a9a1e + 48
    frame #8: 0x0000000043d6056c librustc_codegen_llvm-llvm.so`rustc_codegen_llvm::back::archive::ArchiveBuilder::build::h6c838a83b51bdd6a + 1004
    frame #9: 0x0000000043d3d3ec librustc_codegen_llvm-llvm.so`rustc_codegen_llvm::back::link::link_binary::h4fef911a74f987c6 + 1260
    frame #10: 0x0000000043d16cbc librustc_codegen_llvm-llvm.so`_$LT$rustc_codegen_llvm..LlvmCodegenBackend$u20$as$u20$rustc_codegen_utils..codegen_backend..CodegenBackend$GT$::join_codegen_and_link::_$u7b$$u7b$closure$u7d$$u7d$::h3cc2f3d724071996 (.llvm.4006899775443869056) + 84
    frame #11: 0x0000000043d0fe90 librustc_codegen_llvm-llvm.so`rustc::util::common::time::h054c3c48bc95a312 + 108
    frame #12: 0x0000000043db8df8 librustc_codegen_llvm-llvm.so`_$LT$rustc_codegen_llvm..LlvmCodegenBackend$u20$as$u20$rustc_codegen_utils..codegen_backend..CodegenBackend$GT$::join_codegen_and_link::h47be0ff1cab6ce13 + 580
    frame #13: 0x00000000402f61dc librustc_driver-06c75248988a5cb0.so`rustc_driver::driver::compile_input::hcd6016a540bd0633 + 7296
    frame #14: 0x00000000403864c4 librustc_driver-06c75248988a5cb0.so`rustc_driver::run_compiler_with_pool::h56435960eea75a47 + 2932
…

Comment 15 Mikael Urankar 2018-10-26 17:27:59 UTC

(In reply to Greg V from comment #14)
the crash in jemalloc seems similar to my issue, can you try to recompile rtld-elf natively?

This is what I see on my tx1:
pkg add -f /var/cache/pkg/FreeBSD-clibs-13.0.s20181022155831.txz
Installing FreeBSD-clibs-13.0.s20181022155831...
package FreeBSD-clibs is already installed, forced install
Extracting FreeBSD-clibs-13.0.s20181022155831: 100%

./rustc hello.rs
Segmentation fault (core dumped)
Exit 139

make -C /usr/src/libexec/rtld-elf MK_TESTS=no all install -j5

./rustc hello.rs
./hello                                            
Hello World!

(In reply to mikael.urankar from comment #15)
That did not help (I even built both libc and rtld-elf with DEBUG=-DDEBUG DEBUG_FLAGS=-g), still the same crash.

Comment 17 Mikael Urankar 2018-11-19 13:12:55 UTC

might be related to bug #233204

With https://reviews.freebsd.org/D18417 stage0 builds successfully! But then:

Building stage1 std artifacts (aarch64-unknown-freebsd -> aarch64-unknown-freebsd)
running: "/usr/ports/lang/rust/work/rustc-1.30.1-src/build/aarch64-unknown-freebsd/stage0/bin/cargo" "build" "--target" "aarch64-unknown-freebsd" "-j" "6" "--release" "--frozen" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/usr/ports/lang/rust/work/rustc-1.30.1-src/src/libstd/Cargo.toml" "--message-format" "json"
error: process didn't exit successfully: `/usr/ports/lang/rust/work/rustc-1.30.1-src/build/bootstrap/debug/rustc -vV` (signal: 4, SIGILL: illegal instruction)

It's trying to execute zeros:

Process 18481 launched: '/tmp/rs/work/rustc-1.30.1-src/build/aarch64-unknown-freebsd/stage1/bin/rustc' (aarch64)
Process 18481 stopped
* thread #1, name = 'rustc', stop reason = signal SIGILL: illegal trap
    frame #0: 0x0000000042b10470
->  0x42b10470: .long  0x00000000                ; unknown opcode
    0x42b10474: .long  0x00000000                ; unknown opcode
    0x42b10478: .long  0x00000000                ; unknown opcode
    0x42b1047c: .long  0x00000000                ; unknown opcode
(lldb) bt
* thread #1, name = 'rustc', stop reason = signal SIGILL: illegal trap
  * frame #0: 0x0000000042b10470
    frame #1: 0x0000000040132318

Comment 20 Mikael Urankar 2018-12-12 19:13:17 UTC

fixed with https://reviews.freebsd.org/D18417

bootstrap available for 13. here:
http://mikael.urankar.free.fr/FreeBSD/aarch64/rust-std-1.30.1-aarch64-unknown-freebsd.tar.gz
http://mikael.urankar.free.fr/FreeBSD/aarch64/rustc-1.30.1-aarch64-unknown-freebsd.tar.gz
http://mikael.urankar.free.fr/FreeBSD/aarch64/cargo-0.31.0-aarch64-unknown-freebsd.tar.gz

tested by Greg V and me

Comment 21 commit-hook 2018-12-15 10:39:01 UTC

A commit references this bug:

Author: mmel
Date: Sat Dec 15 10:38:10 UTC 2018
New revision: 342113
URL: https://svnweb.freebsd.org/changeset/base/342113

Log:
  Improve R_AARCH64_TLSDESC relocation.
  The original code did not support dynamically loaded libraries and used
  suboptimal access to TLS variables.
  New implementation removes lazy resolving of TLS relocation - due to flaw
  in TLSDESC design is impossible to switch resolver function at runtime
  without expensive locking.

  Due to this, 3 specialized resolvers are implemented:
   - load time resolver for TLS relocation from libraries loaded with main
     executable (thus with known TLS offset).
   - resolver for undefined thread weak symbols.
   - slower lazy resolver for dynamically loaded libraries with fast path for
     already resolved symbols.

  PR:		228892, 232149, 233204, 232311
  MFC after:	2 weeks
  Differential Revision:	https://reviews.freebsd.org/D18417

Changes:
  head/libexec/rtld-elf/aarch64/reloc.c
  head/libexec/rtld-elf/aarch64/rtld_start.S
  head/libexec/rtld-elf/amd64/reloc.c
  head/libexec/rtld-elf/arm/reloc.c
  head/libexec/rtld-elf/i386/reloc.c
  head/libexec/rtld-elf/mips/reloc.c
  head/libexec/rtld-elf/powerpc/reloc.c
  head/libexec/rtld-elf/powerpc64/reloc.c
  head/libexec/rtld-elf/riscv/reloc.c
  head/libexec/rtld-elf/rtld.c
  head/libexec/rtld-elf/rtld.h
  head/libexec/rtld-elf/sparc64/reloc.c

Comment 22 Tobias Kortkamp 2019-01-06 08:19:30 UTC

*** Bug 225643 has been marked as a duplicate of this bug. ***

Comment 23 Mikael Urankar 2019-01-15 20:49:31 UTC

can we unbreak this port for aarch64?

Comment 24 commit-hook 2019-02-18 15:31:21 UTC

A commit references this bug:

Author: tobik
Date: Mon Feb 18 15:30:45 UTC 2019
New revision: 493268
URL: https://svnweb.freebsd.org/changeset/ports/493268

Log:
  lang/rust: Add aarch64, armv{6,7}, and powerpc64 bootstraps

  PR:		216143, 228892
  Submitted by:	Mika?l Urankar <mikael.urankar@gmail.com>
  Differential Revision:	https://reviews.freebsd.org/D18367

Changes:
  head/lang/rust/Makefile
  head/lang/rust/distinfo
  head/lang/rust/files/patch-src_bootstrap_bootstrap.py
  head/lang/rust/files/patch-src_bootstrap_native.rs
  head/lang/rust/files/patch-src_libbacktrace_fileline.c
  head/lang/rust/files/patch-src_libcompiler__builtins_build.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_freebsd_arm.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_freebsd_mod.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_freebsd_powerpc64.rs
  head/lang/rust/files/patch-src_liblibc_src_unix_bsd_freebsdlike_mod.rs
  head/lang/rust/files/patch-src_librustc__llvm_build.rs
  head/lang/rust/files/patch-src_librustc__target_spec_armv6__unknown__freebsd.rs
  head/lang/rust/files/patch-src_librustc__target_spec_armv7__unknown__freebsd.rs
  head/lang/rust/files/patch-src_librustc__target_spec_mod.rs
  head/lang/rust/files/patch-src_librustc__target_spec_powerpc64__unknown__freebsd.rs
  head/lang/rust/files/patch-src_libstd_build.rs
  head/lang/rust/files/patch-src_libstd_os_raw_mod.rs
  head/lang/rust/files/patch-src_libstd_sys_unix_stack__overflow.rs
  head/lang/rust/files/patch-src_llvm_utils_llvm-build_llvmbuild_main.py
  head/lang/rust/files/patch-vendor_backtrace_src_backtrace_libunwind.rs
  head/lang/rust/files/patch-vendor_libc_src_unix_bsd_freebsdlike_freebsd_arm.rs
  head/lang/rust/files/patch-vendor_libc_src_unix_bsd_freebsdlike_freebsd_mod.rs
  head/lang/rust/files/patch-vendor_libc_src_unix_bsd_freebsdlike_freebsd_powerpc64.rs
  head/lang/rust/files/patch-vendor_libc_src_unix_bsd_freebsdlike_mod.rs
  head/lang/rust/files/patch-vendor_rustc-ap-rustc__target_spec_armv6__unknown__freebsd.rs
  head/lang/rust/files/patch-vendor_rustc-ap-rustc__target_spec_armv7__unknown__freebsd.rs
  head/lang/rust/files/patch-vendor_rustc-ap-rustc__target_spec_mod.rs
  head/lang/rust/files/patch-vendor_rustc-ap-rustc__target_spec_powerpc64__unknown__freebsd.rs

Comment 25 Ed Maste 2019-02-25 17:04:26 UTC

Should this be closed now?

Comment 26 Mikael Urankar 2019-02-25 18:41:18 UTC

(In reply to Ed Maste from comment #25)
yes

Comment 27 Ed Maste 2019-02-25 18:50:04 UTC

Issue has been addressed