Bug 228892 - lang/rust: Fails to build on aarch64
Summary: lang/rust: Fails to build on aarch64
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: FreeBSD Rust Team
URL: http://thunderx1.nyi.freebsd.org/data...
Keywords: needs-qa
Depends on:
Blocks: 201763
  Show dependency treegraph
 
Reported: 2018-06-11 17:11 UTC by Jan Beich
Modified: 2018-12-06 17:48 UTC (History)
5 users (show)

See Also:
dumbbell: maintainer-feedback+
jbeich: merge-quarterly?


Attachments
patch (2.57 KB, patch)
2018-10-24 19:58 UTC, mikael.urankar
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2018-06-11 17:11:30 UTC
running: /wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/build/aarch64-unknown-freebsd/stage0/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/bootstrap/Cargo.toml --frozen
   Compiling unicode-xid v0.1.0
   Compiling serde v1.0.35
   Compiling lazy_static v0.2.11
   Compiling itoa v0.4.1
   Compiling getopts v0.2.15
   Compiling cc v1.0.9
   Compiling cfg-if v0.1.2
   Compiling dtoa v0.4.2
   Compiling num-traits v0.2.2
   Compiling libc v0.2.40
   Compiling build_helper v0.1.0 (file:///wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/build_helper)
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
Fatal error 'inact_mtx enteFatal error 'inactFatal errorr _'mtx'  enat linte 186 eirn fi'le  at il/usr/src/lib/libthr/thread/thr_mutex.cniance  (t_mterrno = 1x8 6e nitn filee r6/usr/src/lib/libthr/thread/thr_mutex.c5535 ()errno
 'error: Could not compile `cfg-if`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `unicode-xid`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `lazy_static`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 Fatal error 'inact_mtx enter' at line 186 in file in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 65535)
/usr/src/lib/libthr/thread/thr_mutex.cerror: Could not compile `itoa`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `dtoa`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `build_helper`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `getopts`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `libc`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `cc`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 65535)
error: Could not compile `num-traits`.
warning: build failed, waiting for other jobs to finish...
Fatal error 'inact_mtx enter' at line 186 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0)
error: Could not compile `serde`.

To learn more, run the command again with --verbose.
Traceback (most recent call last):
  File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/x.py", line 20, in <module>
    bootstrap.main()
  File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/bootstrap/bootstrap.py", line 800, in main
    bootstrap(help_triggered)
  File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/bootstrap/bootstrap.py", line 780, in bootstrap
    build.build_bootstrap()
  File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/bootstrap/bootstrap.py", line 606, in build_bootstrap
    run(args, env=env, verbose=self.verbose)
  File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/bootstrap/bootstrap.py", line 148, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/build/aarch64-unknown-freebsd/stage0/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.26.0-src/src/bootstrap/Cargo.toml --frozen
*** Error code 1
Comment 1 Jean-Sébastien Pédron freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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.
Comment 10 Greg V 2018-08-22 13:57:55 UTC
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.
Comment 12 Greg V 2018-10-25 13:03:00 UTC
(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...
Comment 14 Greg V 2018-10-25 19:53:11 UTC
(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!
Comment 16 Greg V 2018-10-27 16:46:34 UTC
(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
Comment 18 Greg V 2018-12-05 23:23:31 UTC
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)
Comment 19 Greg V 2018-12-06 17:48:40 UTC
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