Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rust_begin_unwind not emitted when crate-type = bin #51671

Closed
japaric opened this issue Jun 21, 2018 · 4 comments · Fixed by #51687
Closed

rust_begin_unwind not emitted when crate-type = bin #51671

japaric opened this issue Jun 21, 2018 · 4 comments · Fixed by #51687

Comments

@japaric
Copy link
Member

japaric commented Jun 21, 2018

STR

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

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

use core::panic::PanicInfo;

#[panic_implementation]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}
$ # linking will fail but that's unimportant
$ cargo build --target thumbv7m-none-eabi
error: linking with `arm-none-eabi-gcc` failed: exit code: 1
  |
  = note: "arm-none-eabi-gcc" "-L" "$SYSROOT/lib/rustlib/thumbv7m-none-eabi/lib" "target/thumbv7m-none-eabi/debug/deps/foo-7e5b7587bde453e1.1y16o1qfye96o7m0.rcgu.o" (..)

$ nm -C target/thumbv7m-none-eabi/debug/deps/foo-7e5b7587bde453e1.1y16o1qfye96o7m0.rcgu.o && echo EMPTY
EMPTY

However if the crate is turned into an rlib the rust_begin_unwind symbol will be emitted.

$ mv src/{main,lib}.rs

$ cargo build --target thumbv7m-none-eabi

$ nm -C target/thumbv7m-none-eabi/debug/deps/libfoo-e1e65e68106e26e1.rlib

foo-e1e65e68106e26e1.1qddbosld5q76e2k.rcgu.o:
(..)
00000001 T rust_begin_unwind
00000000 t $t.0

Metada

$ rustc -V
rustc 1.28.0-nightly (523097979 2018-06-18)

However this problem is also present in nightly-2018-06-03 before #[panic_implementation] landed: rust_begin_unwind is not emitted when the panic_fmt lang item is present in a binary crate.


This issue was found while analyzing #51342 (comment).

@japaric
Copy link
Member Author

japaric commented Jun 21, 2018

I also see that the rust_eh_personality symbol is not emitted when the eh_personality lang item is present in the binary crate. eh_personality could also be affected by this bug, or this may actually be intentional. cc @alexcrichton do you know if this is a bug or intentional?

EDIT: same thing with rust_oom

@japaric
Copy link
Member Author

japaric commented Jun 21, 2018

Interesting. nightly-2017-06-01 does produce the rust_{begin_unwind,eh_personality} symbols, but nightly-2018-01-01 does not so this seems to be a regression.

@japaric
Copy link
Member Author

japaric commented Jun 21, 2018

After bisecting this: nightly-2017-11-08 worked but nightly-2017-11-09 didn't. The most relevant PR that landed between those two releases is #45575, which says:

For executables, cdylibs, and staticlibs, items are only exported if they are additionally #[no_mangle] or have an #[export_name].

It sounds like weak lang items should also be exported in this case as they are effectively #[no_mangle] symbols.

cc @michaelwoerister

japaric added a commit to japaric/rust that referenced this issue Jun 21, 2018
@japaric
Copy link
Member Author

japaric commented Jun 21, 2018

fix in #51687

bors added a commit that referenced this issue Jun 28, 2018
translate / export weak lang items

see #51671 for details

fixes #51671
fixes #51342

r? @michaelwoerister or @alexcrichton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant