panic_implementation: no_mangle attribute needed?

[phil-opp]

When using the new panic_implementation attribute I get a linker error:

  = note: lld: error: undefined symbol: rust_begin_unwind
          >>> referenced by core8-82115649ca0ebad190f7336e649e4ba4.rs
          >>>               core-4aa79020766f2e95.core8-82115649ca0ebad190f7336e649e4ba4.rs.rcgu.o:(core::panicking::panic_fmt::h73e9bd85b453f13d) in archive /…/target/sysroot/lib/rustlib/x86_64-blog_os/lib/libcore-4aa79020766f2e95.rlib

(I'm linking with LLD)

Adding the #[no_mangle] attribute seems to fix this linker error.

Is no_mangle required for the panic function or is this a bug?

[steveklabnik]

I'm seeing this as well.

Additionally, adding no_mangle gives

warning: function is marked #[no_mangle], but not exported
 --> src\panic.rs:6:1
  |
6 |   fn panic(_info: &PanicInfo) -> ! {
  |   ^
  |   |
  |  _help: try making it public: `pub`
  | |
7 | |     unsafe { intrinsics::abort() }
8 | | }
  | |_^
  |
  = note: #[warn(private_no_mangle_fns)] on by default

but it still works. This implies to me that no_mangle shouldn't be needed, as the function doesn't need to be public to work.

[crawford]

I'm seeing the exact same behavior. I'm using arm-none-eabi-ld (2.28.0.20170620) to link.

[japaric]

Can we get more details (steps to reproduce)? Are you all using an allocator? I know there's a linker regression caused by the new-ish oom lang item, which I have reported in #51647. It could be that you are experiencing that bug and that this isn't related to the #[panic_implementation] stuff.

EDIT: I have been using #[panic_implementation] since it landed and have not run into any linker issue but I'm not using an allocator.

[steveklabnik]

https://github.com/intermezzos/kernel is pretty small; download it, remove https://github.com/intermezzOS/kernel/blob/e6508a00ec0bc9ffa417d003d81ae63eceac2cf9/src/panic.rs#L5, and bootimage build

It pretty much happens on 'hello world'; you could strip even more out of the above, if it doesn't warn for you for some reason, I can minimize even further.

Not using an allocator or anything.

[japaric]

@steveklabnik thanks for the sample code. I see at least one bug there: rust_begin_unwind is not emitted when crate-type = bin -- I have reported this with minimal reproduction steps in #51671. I think --{start,end}-group is also missing in the linker invocation but that could be a different issue (or it may fix itself once #51671 is fixed).

[phil-opp]

So I tried it with the latest nightly [1] and the issue still exists for me. To reproduce, try the panic-without-no-mangle branch of https://github.com/phil-opp/blog_os with either bootimage build or env RUST_TARGET_PATH=$(pwd) xargo build --target x86_64-blog_os. Edit: The travis build for that branch also shows the same error.

I also still get the error for intermezzOS.

[1]: rustc 1.29.0-nightly (960f604 2018-07-08)

[crawford]

Ah, thanks for reminding me to verify the fix. I tried removing #[no_mangle] from my code compiled with rustc 1.29.0-nightly (e06c87544 2018-07-06) and I'm hitting the same error as before.

[japaric]

This might be related to #52795.

[alexcrichton]

I believe this is fixed in #52993, where the answer is "no" you shouldn't need #[no_mangle]

[phil-opp]

I can confirm that it now works without no_mangle and pub. Thanks @alexcrichton!

[phil-opp]

Seems like no_mangle is still required in release mode without LTO:

error: linking with `rust-lld` failed: exit code: 1
  |
  = note: rust-lld: error: undefined symbol: rust_oom
          >>> referenced by alloc.rs:224 (liballoc/alloc.rs:224)
          >>>               alloc-c69b28e77453f7a5.alloc.4j3hju2s-cgu.11.rcgu.o:(.text._ZN5alloc5alloc18handle_alloc_error17hcb467c6fec4cebfdE+0x0) in archive /home/philipp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/liballoc-c69b28e77453f7a5.rlib

          
          rust-lld: error: undefined symbol: rust_begin_unwind
          >>> referenced by panicking.rs:77 (libcore/panicking.rs:77)
          >>>               core-59aaa68b41c4baf4.core.82zizo12-cgu.9.rcgu.o:(core::panicking::panic_fmt::h380215f9f52a35ae) in archive /home/philipp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcore-59aaa68b41c4baf4.rlib

It works fine in debug mode and in release mode with LTO. When I add no_mangle, it also works in release mode without LTO. I'm using rustc 1.30.0-nightly (33b923fd4 2018-08-18).

[alexcrichton]

@phil-opp oh dear! Is it possible to get an example I could poke around with?

[phil-opp]

I created a minimal embedded project here: https://github.com/phil-opp/rust-issue-51342-example

> rustup override add nightly
> rustup target add thumbv7em-none-eabihf
> cargo build                                 # works fine
> cargo rustc --release -- -C lto             # works fine
> cargo build --release                       # errors

[alexcrichton]

Oops, thanks for the report! That should be fixed in #53640