ResumeInst needs to be in a function with a personality #18
Comments
|
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: |
|
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. |
|
The branch I linked before has my WIP stuff |
|
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. |
Yeah I am Other differences I can see:
|
Yeah, for a long time the
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... |
|
I'm merging our two branches, and will prune stuff and see if I can get a build working |
👍 I'll be off to bed shortly. I'll expect a magically working compiler in the morning 😈 |
|
Woo, my last hail-Mary effort worked. I guess something doesn't quite get rebuilt properly all the time, so my ; 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
} |
|
I've also gotten the |
|
I've rebuilt twice and am still getting that error, weird. |
|
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. |
|
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 Really, I'm running that process in LLDB, but it forks the real compiler, so I need to do something like: Doing this, I break at the following frames: So it currently looks like we are indeed not setting the personality on the function. |
|
Sounds like an upstream Rust bug, perhaps we should raise it there? |
|
Perhaps. I'm never quite sure how upstream wants to treat LLVM upgrades that they don't need directly. I suppose I could open an issue there later today with the appropriate information. In the worst case, they can close it. |
|
@shepmaster: Does this occur when disabling MIR and using the old backend? |
|
I'm... not sure how to disable MIR anymore... I'm looking, but maybe you recall? |
|
Maybe it was permanently enabled? cb9b0ed |
|
Looks like you're right, that's tricky. I do think it's weird that the only things being done in the IR you posted before:
I don't think any of this would trigger exceptions, it does literally nothing (as per the definition of 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 |
|
The IR validator for 'ResumeInst must be in a function with a personality' was introduced in LLVM commit r277360. We could always quick-fix this by reverting the commit on our fork of LLVM. |
|
I think I may have fixed the bug, will keep this updated. |
|
I've opened #20, although it currently causes a segfault. |
|
I'm pretty happy to revert out the verifier addition in LLVM that caused this breakage and not think about it until upstream Rust fixes this when they next update LLVM tbh |
|
I've fixed the segfault and am upstreaming it in rust-lang#36896 Found another segfault |
|
I think this is the most recent segfault: |
|
I got my debugging info setup correctly: so I don't understand how this code could ever work if |
|
I'm looking at that too. I believe this was broken in r276686. There is still a default constructor for Upstream LLVM regression :( |
So what's the right process here? |
|
We can email The fix will basically be to change this in Archive::Child::Child(const Archive *Parent, const char *Start, Error *Err)
: Parent(Parent), Header(Parent, Start, Parent->getData().size() -
(Start - Parent->getData().data()), Err) {So that it handles |
|
I've just sent an email to |
|
Lang Hames is currently working on a fix, we should be able to update LLVM again after that and we should be good. |
|
This has been fixed as of r283387. I'm merging master in again now. |
|
I needed to rebase on top of master again because Rust stopped building with Apple Clang 8, more merge conflicts, JS backend added, etc. I think I'm on top of it now, we'll see how this build goes. |
|
The |
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
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!
The text was updated successfully, but these errors were encountered: