`rust_begin_unwind` required for panic=abort

[phil-opp]

Since a few nightlies, the compiler requires a rust_begin_unwind symbol again even though my no_std crate uses panic=abort:

In function `core::panicking::panic_fmt::hb1bd46c16a8d9cdb':
core.cgu-0.rs:(.text._ZN4core9panicking9panic_fmt17hb1bd46c16a8d9cdbE+0x38): undefined reference to `rust_begin_unwind'

The big problem is that defining a rust_begin_unwind function in Rust gives an error, too:

error: symbol `rust_begin_unwind` is already defined

I only works if I add a rust_begin_unwind function to a C file that is linked with the Rust crate.

[japaric]

STR

$ cargo new --bin app && cd $_

$ edit Cargo.toml && tail -n2 $_
[profile.dev]
panic = "abort"

$ edit src/main.rs && cat $_
#![feature(lang_items)]
#![no_main]
#![no_std]

#[no_mangle]
pub fn _start() -> ! {
    panic!()
}

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

$ cargo rustc -- -C link-arg=-nostartfiles
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/japaric/.multirust/toolchains/nightly-2016-12-06-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/japaric/tmp/app/target/debug/deps/app-55df21ded2024f97.0.o" "-o" "/home/japaric/tmp/app/target/debug/deps/app-55df21ded2024f97" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/japaric/tmp/app/target/debug/deps" "-L" "/home/japaric/.multirust/toolchains/nightly-2016-12-06-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/japaric/.multirust/toolchains/nightly-2016-12-06-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-1357b93f.rlib" "-nostartfiles"
  = note: /home/japaric/.multirust/toolchains/nightly-2016-12-06-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-1357b93f.rlib(core-1357b93f.0.o): In function `core::panicking::panic_fmt':
/buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/obj/../src/libcore/num/bignum.rs:489: undefined reference to `rust_begin_unwind'
collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: Could not compile `app`.

$ nm -C target/debug/deps/app*.0.o
0000000000000000 t rust_begin_unwind
0000000000000000 N __rustc_debug_gdb_scripts_section__
0000000000000000 T _start
0000000000000000 r str.0
0000000000000000 r str.1
0000000000000000 d app::_start::_MSG_FILE_LINE::h21fcbd8366a7e1b6
                 U core::panicking::panic::h194ce5d68a8f28a1
0000000000000000 t drop::h8b70c8901008835d

Bisecting:

BAD: rustc 1.15.0-nightly (daf8c1dfc 2016-12-05)

GOOD: rustc 1.15.0-nightly (ebeee0e27 2016-12-04)

AFAICT, the difference is that rust_begin_unwind is never a extern/global
symbol in recent nightlies like it used to be:

# with GOOD rustc
$ cargo rustc -- --emit=obj

$ nm -C ./target/debug/deps/app-*.o
0000000000000000 T rust_begin_unwind
0000000000000000 N __rustc_debug_gdb_scripts_section__
0000000000000000 T _start
0000000000000000 r str.0
0000000000000000 r str.1
0000000000000000 d app::_start::_MSG_FILE_LINE::h0939c9c7dafe8539
                 U core::panicking::panic::h194ce5d68a8f28a1
0000000000000000 t drop::he2bf721309cf573a

Changing the extern "C" fn to public doesn't help:

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

# with BAD rustc
$ nm -C ./target/debug/deps/app-*.0.o
0000000000000000 t rust_begin_unwind
0000000000000000 N __rustc_debug_gdb_scripts_section__
0000000000000000 T _start
0000000000000000 r str.0
0000000000000000 r str.1
0000000000000000 d app::_start::_MSG_FILE_LINE::hb927abaa970af5cf
                 U core::panicking::panic::h194ce5d68a8f28a1
0000000000000000 t drop::hc6005949ff734e37

cc @michaelwoerister this may have been caused by #38117

[michaelwoerister]

@japaric That analysis looks pretty correct to me. I suspect that adding #[no_mangle] in addition to pub would solve the problem. But I'll think about what a clean solution would be.

@brson, @alexcrichton: I guess lang-items should always have external linkage?

[alexcrichton]

@michaelwoerister yeah unfortunately things like rust_begin_unwind have to be external, although ideally one day I'd like to fix that!

If it's not already #[no_mangle] and pub it likely should be though, I'd prefer to avoid special-casing these symbols too much.

[michaelwoerister]

@alexcrichton OK.

#[no_mangle] is slightly confusing because the actual symbol name can be different from the function name (as in @japaric's example).

Also, should these symbols be re-exported from (c)dylibs? Probably not, right?

[alexcrichton]

Yeah ideally we wouldn't export rust_begin_unwind from cdylibs, and I don't think it'll be required to link correctly either.

[japaric]

Sorry to be annoyning but a few people that work with the thumbv*-none-eabi* targets have bumped into this and asked about it on the #rust-embedded IRC channel. Is this likely to be fixed soon?

[michaelwoerister]

@japaric Have you tried if adding #[no_mangle] helps?

[pftbest]

@michaelwoerister
Adding #[no_mangle] to panic_fmt helped in my case. So how does this work?
It picks up default panic_fmt when it can't find the custom one?

[michaelwoerister]

The #[no_mangle] attribute just prevents the compiler from hiding the symbol. The compiler generally will try to hide as many symbols as possible because it can make for smaller and faster code and allows LLVM to do more optimizations. The algorithm that determines what to hide has become a little more aggressive recently, which is why this pops up now.

So there is a workaround (i.e. #[no_mangle]) but it's not quite ideal. I'd rather that the compiler knows about these special symbols (or that we require, with a lint for example, that this lang-item and maybe others, have the right name and annotations).

[pftbest]

I know what #[no_mangle] does, what I don't know is why do we get 'rust_begin_unwind is missing' error instead of 'panic_fmt is missing' error.

[michaelwoerister]

Oh, that's because this already has some special handling in the compiler. As far as I can tell, no matter what actual name the function has, if it is marked with #[lang = "panic_fmt"] then it will be assigned "rust_begin_unwind" as symbol name. It's a bit strange.

[pftbest]

@michaelwoerister
Oh, now it makes sense, thank you for explaining.
I was thinking there is some other version of panic_fmt that gets pulled in and makes calls to rust_begin_unwind 😀