Package: libllvm3.8
Version: 1:3.8.1-12
Severity: minor
Dear Maintainer,
#debian-arm
11:03:09 <unixsmurf> infinity0: and yes, stdcall is not supposed to be anything
other than win32 :)
"stdcall" is not supposed to work on arm64, but I felt this bug was weird
enough to warrant a report since it might indicate deeper problems.
All of the below is run on arm64 porterbox asachi.debian.org
$ cat testfiles/test.rs
extern "stdcall" fn extern_stdcall_fn_with_arg(_:bool) {}
fn main() {}
# fails with ours
$ apt-cache policy rustc
rustc:
Installed: 1.10.0+dfsg1-3
[..]
$ rustc testfiles/test.rs
[some rustc warnings]
Segmentation fault
# succeeds with upstream's
# from
https://static.rust-lang.org/dist/rust-1.10.0-aarch64-unknown-linux-gnu.tar.gz
$ rust-1.10.0-aarch64-unknown-linux-gnu/rustc$ bin/rustc -L lib/ -L
../rust-std-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/
../../testfiles/test.rs
[some rustc warnings]
# exit 0
Debian's LLVM 3.8.1-12 only differs from what rustc uses by about 16 commits
(plus patches in debian/patches):
# from https://github.com/rust-lang/llvm.git
# I added the tags for clarity
$ git log --graph --decorate=full --oneline
llvm-debian/3.8.1-12~..rust-upstream/1.11.0
* 80ad955 (HEAD, tag: refs/tags/rust-upstream/1.11.0) [SimplifyCFG] Don't kill
empty cleanuppads with multiple uses
* a73c41e [ArgumentPromotion] Propagate operand bundles to promoted call sites
* 7513452 Fix PR25339: ARM Constant Island
* 80fab33 [WinEH] Don't inline an 'unwinds to caller' cleanupret into funclets
which locally unwind
* 25c7dc3 [AA] Hoist the logic to reformulate various AA queries in terms of
other parts of the AA interface out of the base class of every single AA result
object.
* 361ff3b [PM/AA] Actually wire the AAManager I built for the new pass manager
into the new pass manager and fix the latent bugs there.
* 4f2b179 Add an "addUsedAAAnalyses" helper function
* 63f3a1b Add Rust's personality function to the list of known personality
functions
* 3dcd2c8 Fix the freebsd building on Windows
* be89e4b Fix cross-compiling to FreeBSD
* deb2692 Don't compile usage of std::thread
* d16f119 [WinEH] Don't perform state stores in cleanups
* 9cc2b72 Add support for i1 compare operations to X86 FastISel, and ignore
llvm.assume() intrinsics in the target-independent FastISel.
* 4d5a6d7 Fix compile on older clang/OSX versions
* cca16c0 Add some Rust allocation functions to TargetLibraryInfo +
MemoryBuiltins
* de62574 Disable the PassInfo cache assertions to make the cache effective in
builds with assertions enabld
* ad57503 (tag: refs/tags/llvm-debian/3.8.1-12) ReleaseNotes: tidy up
However, I have recompiled our LLVM with these commits and it *still* crashes.
Backtrace:
Thread 2 "rustc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fb29feea0 (LWP 25806)]
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 0x0000007fb3cd0268 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(0xe835bbb9cff19d85)
referenced by CU at offset 0xb785 [in module
/home/infinity0/llvm-toolchain-3.8-3.8.1/debian/tmp/usr/lib/llvm-3.8/lib/libLLVM-3.8.so.1]
#2 0x0000007fb3ce6f60 in
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () at
/home/infinity0/llvm-toolchain-3.8-3.8.1/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1221
#3 0x0000007fb3ce7cfc 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(0xa7d37fd1eb23ffc9)
referenced by CU at offset 0x95cd [in module
/home/infinity0/llvm-toolchain-3.8-3.8.1/debian/tmp/usr/lib/llvm-3.8/lib/libLLVM-3.8.so.1]
#4 0x0000007fb3998b44 in llvm::FPPassManager::runOnFunction(llvm::Function&)
() at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1547
#5 0x0000007fb3998e7c in llvm::FPPassManager::runOnModule(llvm::Module&) () at
/home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1568
#6 0x0000007fb39991ac in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
at /home/infinity0/llvm-toolchain-3.8-3.8.1/lib/IR/LegacyPassManager.cpp:1624
#7 0x0000007fb585553c in LLVMRustWriteOutputFile () from
/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_llvm-e8edd0fd.so
which is basically the same as what happens before I patched in those commits
https://github.com/rust-lang/rust/issues/36348#issuecomment-246129828
The strange thing is that our LLVM segfaults but rustc's succeeds. Ideally,
both should give a nice error message, or at least hit this assertion:
lib/Target/AArch64/AArch64ISelLowering.cpp:2352:
llvm_unreachable("Unsupported calling convention.");
I am currently working around this for our rustc by applying the patches I
mentioned here:
https://github.com/rust-lang/rust/issues/36348#issuecomment-246130324
https://github.com/rust-lang/rust/issues/36348#issuecomment-246169467
X
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
