LTO causes undefined references to core::panicking::panic

[rust-lang]

LTO causes undefined references to core::panicking::panic

[japaric]

I couldn't set up the 3ds dev environment but still managed to reproduce this with:

// src/main.rs
#![feature(lang_items)]
#![no_main]
#![no_std]

extern crate rustc_builtins;

use core::ptr;

#[no_mangle]
pub unsafe fn _start() -> u32 {
    let x = ptr::read_volatile(0x0 as *const u32);
    let y = ptr::read_volatile(0x0 as *const u32);

    x / y
}

#[no_mangle]
pub fn __aeabi_unwind_cpp_pr0() {}

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

# Cargo.toml
[package]
name = "foo"
version = "0.1.0"
authors = ["Jorge Aparicio <[email protected]>"]

[dependencies]
rustc_builtins = { git = "https://github.com/japaric/rustc-builtins" }

[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"
lto = true

# .cargo/config
[build]
rustflags = ["-C", "link-arg=-nostartfiles"]

// thumbv6m-none-eabi.json
{
    "arch": "arm",
    "data-layout": "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64",
    "executables": true,
    "features": "+strict-align",
    "linker": "arm-none-eabi-gcc",
    "llvm-target": "thumbv6m-none-eabi",
    "os": "none",
    "target-endian": "little",
    "target-pointer-width": "32"
}

$ xargo build --target thumbv6m-none-eabi --release
   Compiling foo v0.1.0 (file:///home/japaric/tmp/foo)
error: linking with `arm-none-eabi-gcc` failed: exit code: 1
  |
  = note: "arm-none-eabi-gcc" "-L" "/home/japaric/.xargo/lib/rustlib/thumbv6m-none-eabi/lib" "/home/japaric/tmp/foo/target/thumbv6m-none-eabi/release/foo.0.o" "-o" "/home/japaric/tmp/foo/target/thumbv6m-none-eabi/release/foo" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/japaric/tmp/foo/target/thumbv6m-none-eabi/release/deps" "-L" "/home/japaric/.xargo/lib/rustlib/thumbv6m-none-eabi/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/tmp/rustc.Jxy0hf5HsfzM/librustc_builtins-5c8a87f356eb958c.rlib" "-nostartfiles"
  = note: /tmp/rustc.Jxy0hf5HsfzM/librustc_builtins-5c8a87f356eb958c.rlib(rustc_builtins-5c8a87f356eb958c.0.o): In function `__aeabi_uidiv':
rustc_builtins.cgu-0.rs:(.text.__aeabi_uidiv+0xde): undefined reference to `core::panicking::panic::h2a0ea99cd46c9ef6'
collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: Could not compile `foo`.

To learn more, run the command again with --verbose.
error: `cargo` process didn't exit successfully

[japaric]

So, what I think is happening is that, because core participates in LTO but rustc_builtins doesn't, LLVM looks at _start and says "oh, this can't panic let's drop the panicking::panic symbol". After LTO, the object looks like this

(this is foo.0.o)

00000000 <_start>:
   0:   b580            push    {r7, lr}
   2:   2100            movs    r1, #0
   4:   6808            ldr     r0, [r1, #0]
   6:   6809            ldr     r1, [r1, #0]
   8:   f7ff fffe       bl      0 <__aeabi_uidiv>
   c:   bd80            pop     {r7, pc}

Disassembly of section .text.__aeabi_unwind_cpp_pr0:

00000000 <__aeabi_unwind_cpp_pr0>:
   0:   4770            bx      lr

Disassembly of section .text.rust_begin_unwind:

00000000 <rust_begin_unwind>:
   0:   4770            bx      lr

Note that there is an undefined reference to __aeabi_uidiv (this is expected).

But then when linking happens, the linker links in the __aeabi_uidiv symbol but that symbol depends on panicking::panic and there is no other object that provides it! The core crate has the panicking::panic symbol but that crate doesn't participate in the linking process because it already was LTOed.

[japaric]

I think what we could do is:

• Have rustc_builtins participate in LTO. But than would bring back the infinite recursive call problem with __aeabi_memcpy.
• Don't use anything that's in core in the rustc_builtins crate. This is a non-starter.
• Perhaps, have rustc_builtins participate in LTO but isolate the symbols that have the infinite recursive call problem into another crate that doesn't participate in LTO. rustc_builtins would depend on that other crate.
• Don't use panic! in rustc_builtins. That would fix this particular case but there would still be problems with other symbols defined in core that get used in rustc_builtins but that don't get used in the top-crate/executable.

cc @alexcrichton

[Amanieu]

Another alternative: move the memcpy stuff (including the aeabi aliases) to a separate no_builtin crate.

[japaric]

@Amanieu yeah, that's the third alternative I mentioned 😄.

[alexcrichton]

Morally I feel like "Don't use anything that's in core in the rustc_builtins crate" is the correct approach here because that's what the dependencies actually look like. Perhaps though we could tweak this to "Don't use any symbol that's in core in the rustc_builtins crate".

That is, almost all of libcore is tagged with #[inline], and we're already looking at symbols in the compiled output, so perhaps we could assert that there are no undefined symbols that we don't know about?

[japaric]

@alexcrichton

$ nm -u target/debug/librustc_builtins.rlib

rustc_builtins.0.o:
                 U rust_eh_personality
                 U _Unwind_Resume
                 U _ZN4core9panicking5panic17h1a2d1a6b50eaa468E

$ nm -u target/release/librustc_builtins.rlib

rustc_builtins.0.o:
                 U _ZN4core9panicking5panic17h1a2d1a6b50eaa468E

Should we stop using panic! in our implementation and switch to compilerrt_abort?

On that note, the libcompiler-rt.a that we used to distribute is filled with undefined compilerrt_abort_impl symbols. I don't know how that used to work.

[alexcrichton]

Yeah in my mind this crate should never panic, but if it must be fallible it's safe to tear down everything.

[japaric]

Yeah in my mind this crate should never panic

Some of the implementations have branches that panic for stuff like division by zero but we should never reach those paths because Rust would trigger a panic before those intrinsics are called (I can't where in the compiler this behavior is implemented).

I think the only way to reach those branches is to directly call the intrinsic (unsafe) with input = 0 or use the intrinsics::unchecked_div in the standard library. unchecked_div says that it's UB to call it with denominator = 0. Does that give us permission to replace the panics in our division by zero branches with intrinsics::unreachable?

[alexcrichton]

I'd prefer to stick with intrinsics::abort for now, but in general I think unreachable should be ok in the long term (once we've verified everything)

[alexcrichton]

Some more guards for this were added in #166, so I think this is resolved.

[BartMassey]

This seems to have regressed again. ssh://[email protected]/BartMassey/mixy on Linux/x86-64, remove the -O flag in the Makefile. Shall I file a separate issue for the regression?

[alexcrichton]

@BartMassey yes please do!

[BartMassey]

@alexcrichton Issue #245. I think it's probably all my fault, but I'm not sure exactly what to do, so…