panic_implementation: no_mangle attribute needed?

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?

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.

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

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.

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.

@steveklabnik

@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).

translate / export weak lang items

Auto merge of #51687 - japaric:gh51671, r=alexcrichton

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)

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.

This might be related to #52795.

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

Auto merge of #52993 - alexcrichton:fix-some-vis, r=michaelwoerister

@alexcrichton

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

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).

@phil-opp

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

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

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

Auto merge of #53640 - alexcrichton:more-symbol-tweaks, r=michaelwoer…

Navigation Menu

Repository navigation

panic_implementation: no_mangle attribute needed? #51342

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

panic_implementation: no_mangle attribute needed? #51342

Description

Activity

steveklabnik commented on Jun 5, 2018

crawford commented on Jun 10, 2018

japaric commented on Jun 20, 2018

steveklabnik commented on Jun 20, 2018

japaric commented on Jun 21, 2018

phil-opp commented on Jul 9, 2018

crawford commented on Jul 10, 2018

japaric commented on Jul 27, 2018

alexcrichton commented on Aug 2, 2018

phil-opp commented on Aug 17, 2018

phil-opp commented on Aug 20, 2018

alexcrichton commented on Aug 20, 2018

phil-opp commented on Aug 21, 2018

alexcrichton commented on Aug 23, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions