ResumeInst needs to be in a function with a personality

[shepmaster]

Trying to update to avr-llvm/llvm@3c0d2ad, I've made some good progress and some nasty hacks, but now I'm stuck at this intriguing LLVM error

ResumeInst needs to be in a function with a personality.
  resume { i8*, i32 } %3
LLVM ERROR: Broken function found, compilation aborted!

Unfortunately, I have not been able to generate an LLVM IR dump of the invalid input before the failure occurs, and I can't get useful debugging symbols in LLVM or add debugging prints to the LLVM codebase. Frustrating!

[dylanmckay]

Interesting, I'm not getting that.

I've been working off the branch you pushed before

https://github.com/avr-rust/rust/commits/avr-support-4.0

I am getting this error though:

Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file //Users//dylanmckay//projects//avr-rust//rust//src//llvm//include/llvm/Support/Casting.h, line 237.

[dylanmckay]

Pretty sure we duplicated a bunch of stuff

[shepmaster]

Pretty sure we duplicated a bunch of stuff

That wouldn't be too surprising, but I definitely hacked-and-slashed some stuff to get it working. There's a few places where I lost functionality. Do you have a branch of your in-progress changes? Maybe something will jump out at us if we compare the two.

[dylanmckay]

The branch I linked before has my WIP stuff

[shepmaster]

Oh, I didn't even notice it was in this repo ;-)

I do notice that you are building LLVM inside of the Rust directory; are you letting the Rust build process drive that? I've got LLVM built in a separate directory and am linking to it.

[dylanmckay]

are you letting the Rust build process drive that?

Yeah I am

Other differences I can see:

• You're using the beta bootstrap stuff instead of the configure script like myself
• You've got a bunch more inlining-related stuff on your branch, whereas I've got your initial inlining stuff in my branch

[shepmaster]

You're using the beta bootstrap stuff instead of the configure script like myself

Yeah, for a long time the configure script couldn't handle the CMake-based LLVM. That was addressed when they wanted to upgrade to 3.9 for Emscripten, but I'm still used to the way that I got working ;-)

a bunch more inlining-related stuff

I don't know that there's a bunch more, but I think I changed it from the initial commit because I got missing symbol errors, which might be fixed from your inclusion of the Objective-C library...

[dylanmckay]

I'm merging our two branches, and will prune stuff and see if I can get a build working

[shepmaster]

I'm merging our two branches

👍 I'll be off to bed shortly. I'll expect a magically working compiler in the morning 😈

[shepmaster]

Woo, my last hail-Mary effort worked. I guess something doesn't quite get rebuilt properly all the time, so my make clean helped:

; Function Attrs: inlinehint uwtable
define internal void @_ZN4core3mem6forget17h6a12bc5fd51e1250E(i64) unnamed_addr #2 !dbg !633 {
entry-block:
  %arg0 = alloca i64
  %t = alloca i64
  %personalityslot = alloca { i8*, i32 }
  store i64 %0, i64* %arg0
  call void @llvm.dbg.declare(metadata i64* %arg0, metadata !641, metadata !642), !dbg !643
  call void @llvm.dbg.declare(metadata i64* %t, metadata !644, metadata !642), !dbg !646
  br label %start

start:                                            ; preds = %entry-block
  %1 = load i64, i64* %arg0, !dbg !647
  store i64 %1, i64* %t, !dbg !647
  %2 = load i64, i64* %t, !dbg !648
  br label %bb2, !dbg !648

bb1:                                              ; No predecessors!
  %3 = load { i8*, i32 }, { i8*, i32 }* %personalityslot, !dbg !647
  resume { i8*, i32 } %3

bb2:                                              ; preds = %start
  ret void, !dbg !646
}

[dylanmckay]

I've also gotten the ResumeInst error after merging the two branches. I'll try cleaning and rebuilding

[dylanmckay]

I've rebuilt twice and am still getting that error, weird.

[dylanmckay]

Looks like others have had this bug before too

https://botbot.me/mozilla/rust-internals/2016-08-11/?msg=71118645&page=1

That must mean that it's unrelated to our changes, and is an incompatibility between LLVM 4.0 and 3.9

nagisa suggests that it's likely to be an ABI incompatibility that's causing it.

[shepmaster]

I've got a very hacky reproduction:

#![feature(lang_items)]
#![feature(start)]
#![feature(intrinsics)]
#![feature(no_core)]
#![feature(on_unimplemented)]
#![feature(fundamental)]

#![no_std]
#![no_core]

#[start]
fn start(_argc: isize, _argv: *const *const u8) -> isize {
    forget(42);
    0
}

#[lang = "eh_personality"]
extern fn eh_personality() {}

#[lang = "panic_fmt"]
extern fn panic_fmt() -> ! { loop {} }

mod intrinsics {
    extern "rust-intrinsic" {
        pub fn forget<T>(_: T) -> ();
    }
}

#[inline]
pub fn forget<T>(t: T) {
    unsafe { intrinsics::forget(t) }
}

#[lang = "sized"]
#[rustc_on_unimplemented = "`{Self}` does not have a constant size known at compile-time"]
#[fundamental]
pub trait Sized {}

#[lang = "copy"]
pub trait Copy {}

And this is how I reproduce

RUSTC="/Users/shep/Projects/avr-rust/debug/build/bootstrap/debug/rustc" \
RUSTC_BOOTSTRAP_KEY="836a4172" \
RUSTC_LIBDIR="/Users/shep/Projects/avr-rust/debug/build/x86_64-apple-darwin/stage1/lib" \
RUSTC_REAL="/Users/shep/Projects/avr-rust/debug/build/x86_64-apple-darwin/stage1/bin/rustc" \
RUSTC_SNAPSHOT="/Users/shep/Projects/avr-rust/debug/build/x86_64-apple-darwin/stage0/bin/rustc" \
RUSTC_SNAPSHOT_LIBDIR="/Users/shep/Projects/avr-rust/debug/build/x86_64-apple-darwin/stage0/lib" \
RUSTC_STAGE="1" \
RUSTC_SYSROOT="/Users/shep/Projects/avr-rust/debug/build/x86_64-apple-darwin/stage1" \
/Users/shep/Projects/avr-rust/debug/build/bootstrap/debug/rustc \
/tmp/repro.rs \
--crate-type lib \
--emit=link \
--target x86_64-apple-darwin

Really, I'm running that process in LLDB, but it forks the real compiler, so I need to do something like:

# LLDB #1
(lldb) env ...env...
(lldb) b fork
(lldb) r ...args...
# LLDB #2
(lldb) attach -w -n rustc
# LLDB #1
(lldb) c
# LLDB #2
(lldb) br set -r '.*personality.*'
(lldb) br set -r '.*Personality.*'
(lldb) c

Doing this, I break at the following frames:

rustc::middle::lang_items::{{impl}}::eh_personality at lang_items.rs:136
rustc_trans::mir::block::{{impl}}::get_personality_slot at block.rs:758
rustc_trans::mir::block::{{impl}}::get_personality_slot::{{closure}} at block.rs:764
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const
llvm::Function::hasPersonalityFn() const

So it currently looks like we are indeed not setting the personality on the function.