rustc 1.11.0 arm64 failed to compile debuginfo-gdb/type-names.rs

[infinity0]

Failure here, relevant snippet:

failures:

---- [debuginfo-gdb] debuginfo-gdb/type-names.rs stdout ----


executing aarch64-unknown-linux-gnu/stage2/bin/rustc /«BUILDDIR»/rustc-1.11.0+dfsg1/src/test/debuginfo/type-names.rs -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/ --target=aarch64-unknown-linux-gnu -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu.debuginfo-gdb.libaux -C prefer-dynamic -o aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu -C link-args=-Wl,-z,relro --cfg rtopt -C rpath -L aarch64-unknown-linux-gnu/rt -g
------stdout------------------------------

------stderr------------------------------

------------------------------------------

error: compilation failed!
status: signal: 11
command: aarch64-unknown-linux-gnu/stage2/bin/rustc /«BUILDDIR»/rustc-1.11.0+dfsg1/src/test/debuginfo/type-names.rs -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/ --target=aarch64-unknown-linux-gnu -L aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu.debuginfo-gdb.libaux -C prefer-dynamic -o aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu -C link-args=-Wl,-z,relro --cfg rtopt -C rpath -L aarch64-unknown-linux-gnu/rt -g
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

------------------------------------------

thread '[debuginfo-gdb] debuginfo-gdb/type-names.rs' panicked at 'explicit panic', /«BUILDDIR»/rustc-1.11.0+dfsg1/src/tools/compiletest/src/runtest.rs:2243
stack backtrace:
   1:       0x7fb4edc84f - std::sys::backtrace::tracing::imp::write::h46e546df6e4e4fe6
   2:       0x7fb4ee9043 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h077deeda8b799591
   3:       0x7fb4ee8acf - std::panicking::default_hook::heb8b6fd640571a4f
   4:       0x7fb4eb23d7 - std::panicking::rust_panic_with_hook::hd7b83626099d3416
   5:       0x555e330577 - std::panicking::begin_panic::hf17b963d1d3f11f5
   6:       0x555e3455cb - compiletest::runtest::ProcRes::fatal::h96be905edb55698f
   7:       0x555e35785f - compiletest::runtest::TestCx::fatal_proc_rec::h8398deadc2d3481b
   8:       0x555e35f287 - compiletest::runtest::TestCx::run_debuginfo_gdb_test_no_opt::h693619ce1093299a
   9:       0x555e34d0a3 - compiletest::runtest::TestCx::run_revision::haae9eca9e8cfdcc0
  10:       0x555e334b7b - _<F as alloc..boxed..FnBox<A>>::call_box::hb25f1d3f86806d7d
  11:       0x7fb52be4f3 - std::panicking::try::call::h62a4455a05e6ba27
  12:       0x7fb4ef3f8b - __rust_try
  13:       0x7fb4ef3f23 - __rust_maybe_catch_panic
  14:       0x7fb52be8f7 - _<F as alloc..boxed..FnBox<A>>::call_box::h665ae3a23f3a9576
  15:       0x7fb4ee71a3 - std::sys::thread::Thread::new::thread_start::hf2eed4b6f7149599
  16:       0x7fb4c18017 - <unknown>


failures:
    [debuginfo-gdb] debuginfo-gdb/type-names.rs

test result: FAILED. 97 passed; 1 failed; 5 ignored; 0 measured

thread 'main' panicked at 'Some tests failed', /«BUILDDIR»/rustc-1.11.0+dfsg1/src/tools/compiletest/src/main.rs:293
stack backtrace:
   1:       0x7fb4edc84f - std::sys::backtrace::tracing::imp::write::h46e546df6e4e4fe6
   2:       0x7fb4ee9043 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h077deeda8b799591
   3:       0x7fb4ee8bd7 - std::panicking::default_hook::heb8b6fd640571a4f
   4:       0x7fb4eb23d7 - std::panicking::rust_panic_with_hook::hd7b83626099d3416
   5:       0x555e330577 - std::panicking::begin_panic::hf17b963d1d3f11f5
   6:       0x555e329c47 - compiletest::main::h9488a95819777ee7
   7:       0x7fb4ee83d7 - std::panicking::try::call::hca715a47aa047c49
   8:       0x7fb4ef3f8b - __rust_try
   9:       0x7fb4ef3f23 - __rust_maybe_catch_panic
  10:       0x7fb4ee7dbb - std::rt::lang_start::h162055cb2e4b9fe7
  11:       0x7fb4ca3363 - <unknown>
/«BUILDDIR»/rustc-1.11.0+dfsg1/mk/tests.mk:760: recipe for target 'tmp/check-stage2-T-aarch64-unknown-linux-gnu-H-aarch64-unknown-linux-gnu-debuginfo-gdb.ok' failed
make[2]: *** [tmp/check-stage2-T-aarch64-unknown-linux-gnu-H-aarch64-unknown-linux-gnu-debuginfo-gdb.ok] Error 101
make[2]: *** Waiting for unfinished jobs....

[michaelwoerister]

Looks like a segmentation fault. Maybe a problem in LLVM? The Rust side doesn't do anything architecture specific, as far as I know.

[infinity0]

We are using not-rust's-fork of LLVM for this, yes. I'll have to investigate further later.

[TimNN]

This may be #36023, which was indeed fixed by backporting an llvm patch in #36117.

[michaelwoerister]

@infinity0: If it's really the issue @TimNN mentions, is there something you can do about that?

[infinity0]

Yes, I can have it backported to Debian's LLVM no problem. I just need some time to test and check that it does fix the issue.

[infinity0]

OK, I'm fairly sure the patch @TimNN mentioned does not fix the issue, at least not by itself. (I don't have root on the arm64 machine I have access to, so I can't patch the system LLVM, but I set --llvm-root for the rustc build to the custom one I patched and built. So I should be doing things the right way.)

[infinity0]

I have the build environment and all the build files intact however, so let me know if I can run extra things for a better diagnosis.

[infinity0]

Here's a backtrace:

Thread 2 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb2bfeed0 (LWP 6685)]
getCopyFromParts(llvm::SelectionDAG&, llvm::SDLoc, llvm::SDValue const*, unsigned int, llvm::MVT, llvm::EVT, llvm::Value const*, llvm::ISD::NodeType) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/include/llvm/CodeGen/SelectionDAGNodes.h:706
706         return ValueList[ResNo];
(gdb) bt
#0  getCopyFromParts(llvm::SelectionDAG&, llvm::SDLoc, llvm::SDValue const*, unsigned int, llvm::MVT, llvm::EVT, llvm::Value const*, llvm::ISD::NodeType) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/include/llvm/CodeGen/SelectionDAGNodes.h:706
#1  0x0000007fb3d9aea8 in llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7533
warning: Could not find DWO CU CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGISel.cpp.dwo(0x63d611a14ea36bbf) referenced by CU at offset 0xb7b9 [in module /home/infinity0/vroot/usr/lib/debug/.build-id/38/1a430b7891664d86e253c9a285580437205637.debug]
#2  0x0000007fb3db1ba0 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1221
#3  0x0000007fb3db293c in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:502
warning: Could not find DWO CU CMakeFiles/LLVMCore.dir/LegacyPassManager.cpp.dwo(0xe2d0d448fbcb5d61) referenced by CU at offset 0x9601 [in module /home/infinity0/vroot/usr/lib/debug/.build-id/38/1a430b7891664d86e253c9a285580437205637.debug]
#4  0x0000007fb3a60dc4 in llvm::FPPassManager::runOnFunction(llvm::Function&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1550
#5  0x0000007fb3a610fc in llvm::FPPassManager::runOnModule(llvm::Module&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1571
#6  0x0000007fb3a6142c in llvm::legacy::PassManagerImpl::run(llvm::Module&) () at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1627
#7  0x0000007fb60ad954 in LLVMRustWriteOutputFile (Target=<optimized out>, PMR=<optimized out>, M=<optimized out>, path=<optimized out>, FileType=<optimized out>) at ./src/rustllvm/PassWrapper.cpp:310
#8  0x0000007fb7487954 in rustc_trans::back::write::write_output_file::h6987760832c57d2e () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#9  0x0000007fb74898ec in rustc_trans::back::write::optimize_and_codegen::_$u7b$$u7b$closure$u7d$$u7d$::h965e55032de68f69 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#10 0x0000007fb74902a0 in rustc_trans::back::write::execute_work_item::h46f7bca878f71bc1 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#11 0x0000007fb748a614 in rustc_trans::back::write::run_passes::h4610f818f672d1a8 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_trans-39b92f95.so
#12 0x0000007fb7e81298 in rustc_driver::driver::phase_5_run_llvm_passes::h283134306ba7308a () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#13 0x0000007fb7e3d1b8 in rustc_driver::driver::compile_input::hdfe4405d66704c31 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#14 0x0000007fb7e2c114 in rustc_driver::run_compiler::h581448fb74257353 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#15 0x0000007fb7e294f8 in std::panicking::try::call::hf081e8ea5e252d1a () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#16 0x0000007fb7b54f8c in __rust_try () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/libstd-39b92f95.so
#17 0x0000007fb7b54f24 in __rust_maybe_catch_panic () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/libstd-39b92f95.so
#18 0x0000007fb7e29f60 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h2d5dcb354b3ff8db () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/librustc_driver-39b92f95.so
#19 0x0000007fb7b481a4 in std::sys::thread::Thread::new::thread_start::hf2eed4b6f7149599 () from /home/infinity0/rustc-1.11.0+dfsg1/aarch64-unknown-linux-gnu/stage2/bin/../lib/libstd-39b92f95.so
#20 0x0000007fb585a018 in start_thread () from /lib/aarch64-linux-gnu/libpthread.so.0
#21 0x0000007fb79cdd18 in ?? () from /lib/aarch64-linux-gnu/libc.so.6

I am using Debian's LLVM 3.8.1-12 with this patch applied. I ran the following commands to get the above backtrace:

$ cat ./recomp-gdb.sh 
#!/bin/sh
exec gdb -d "../llvm-toolchain-3.8-3.8.1" -ex "set debug-file-directory $HOME/vroot/usr/lib/debug" -ex "run ./recomp.sh" sh

$ cat ./recomp.sh 
#!/bin/sh
export RUSTC_BOOTSTRAP_KEY=39b92f95
export RUST_BACKTRACE=1
export LD_LIBRARY_PATH=/home/infinity0/vroot/usr/lib/llvm-3.8/lib
# the below is what the test claims to be running, c+p from its output:
exec aarch64-unknown-linux-gnu/stage2/bin/rustc \
/home/infinity0/rustc-1.11.0+dfsg1/src/test/debuginfo/type-names.rs \
-L aarch64-unknown-linux-gnu/test/debuginfo-gdb/ \
--target=aarch64-unknown-linux-gnu \
-L aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu.debuginfo-gdb.libaux \
-C prefer-dynamic \
-o aarch64-unknown-linux-gnu/test/debuginfo-gdb/type-names.stage2-aarch64-unknown-linux-gnu \
-C link-args=-Wl,-z,relro --cfg rtopt -C rpath -L aarch64-unknown-linux-gnu/rt -g

[infinity0]

I can make the segfault go away (the test compiles) if I comment out the following two lines:

--- src/test/debuginfo/type-names.rs.orig       2016-09-10 19:14:05.466433219 +0000
+++ src/test/debuginfo/type-names.rs    2016-09-10 19:12:35.384131562 +0000
@@ -224,7 +224,7 @@
 fn rust_fn_with_return_value(_: f64) -> usize { 4 }
 extern "C" fn extern_c_fn_with_return_value() -> Struct1 { Struct1 }
 unsafe fn unsafe_fn_with_return_value(_: GenericStruct<u16, u8>) -> mod1::Struct2 { mod1::Struct2 }
-extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }
+//extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }

 fn generic_function<T>(x: T) -> T { x }

@@ -315,7 +315,7 @@
     let rust_fn_with_return_value = (rust_fn_with_return_value, 0_usize);
     let extern_c_fn_with_return_value = (extern_c_fn_with_return_value, 0_usize);
     let unsafe_fn_with_return_value = (unsafe_fn_with_return_value, 0_usize);
-    let extern_stdcall_fn_with_return_value = (extern_stdcall_fn_with_return_value, 0_usize);
+//    let extern_stdcall_fn_with_return_value = (extern_stdcall_fn_with_return_value, 0_usize);

     let generic_function_int = (generic_function::<isize>, 0_usize);
     let generic_function_struct3 = (generic_function::<mod1::mod2::Struct3>, 0_usize);

of course the test fails because it's missing the expected output, but perhaps this can help you diagnose the problem.

[TimNN]

Could this be related to #36142?

[infinity0]

Possibly yes. If I read things right, "stdcall" is x86 specific so it shouldn't be present in a cross-platform test, or at least it should be enabled only for a particular platform. So the segfault is just a secondary here; though of course there could be a better error message instead of a segfault.

Looking through git grep, there are other tests that also have "stdcall" in them (e.g. run-pass/extern-methods.rs), and probably should be disabled or put behind an architecture-specific gate.

However after doing a bit more research I'm confused. On the successful Debian arm64 build of 1.10.0 we see:

test [debuginfo-gdb] debuginfo-gdb/type-names.rs ... ignored
[..]
test [run-pass] run-pass/extern-methods.rs ... ok

Neither of these tests changed between 1.10.0 and 1.11.0 so I'm wondering (a) why 1.11.0 doesn't ignore type-names like 1.10.0 does, and (b) how it managed to run extern-methods successfully...

[infinity0]

On second thoughts, I don't think this is related to #36142. I can make the test pass by further commenting out the test case for extern_stdcall_fn_with_return_value, i.e.:

--- src/test/debuginfo/type-names.rs.orig       2016-09-10 19:14:05.466433219 +0000
+++ src/test/debuginfo/type-names.rs    2016-09-11 08:47:57.833460343 +0000
@@ -153,9 +153,6 @@
 // gdb-command:whatis unsafe_fn_with_return_value
 // gdb-check:type = struct (unsafe fn(type_names::GenericStruct<u16, u8>) -> type_names::mod1::Struct2, usize)

-// gdb-command:whatis extern_stdcall_fn_with_return_value
-// gdb-check:type = struct (extern "stdcall" fn(Box<isize>) -> usize, usize)
-
 // gdb-command:whatis generic_function_int
 // gdb-check:type = struct (fn(isize) -> isize, usize)

in additional to the other patch above. So arm64 can compile and test extern_stdcall_fn just fine, but fails with extern_stdcall_fn_with_return_value (which also has an extra argument).

[infinity0]

Minimal test case, fails even on rustc 1.10 (with Debian's LLVM):

$ cat test.rs
extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }
fn main() {}

$ rustc test.rs 
test.rs:1:1: 1:86 warning: function is never used: `extern_stdcall_fn_with_return_value`, #[warn(dead_code)] on by default
test.rs:1 extern "stdcall" fn extern_stdcall_fn_with_return_value(_: Box<isize>) -> usize { 0 }
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Segmentation fault

However this does seem like a Debian-specific issue; I can't reproduce this with upstream 1.10 or 1.11.

[infinity0]

Continued in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837533. I think in general rust should just remove these "stdcall" tests or move them into a separate test that is only run on the appropriate platforms.