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.