Undefined reference to core::panicking::panic

[BartMassey]

I have a little crate at http://gitlab.com/BartMassey/mixy that I have been compiling on Debian Linux x86-64 as a demo of providing Rust functions to C code. I'm using nightly Rust so that I can use lang_items to make no_std and no_builtins work.

Today I discovered the "--emit=obj" compiler option and decided to try it out. Compiled fine, but at the link stage (using gcc) I got

    rusty.o: In function `rust_add': rusty0-8787f43e282added376259c1adb08b80.rs (.text.rust_add+0x1c): undefined reference to `core::panicking::panic'

After discovering issue #79, I tried rustc -O and it worked.

I'm sure the panic in the not -O case is because rustc is checking the addition for overflow and planning to panic if it did. I'm hoping there's some way I can wire that panic to a hard abort, because in more complicated cases it would be a pain to rewrite all the arithmetic and besides checking adds in debug mode seems nice. Honestly, I would prefer to at least be able to check them in release code also.

I'm probably all kinds of confused, and reporting to the wrong place besides, but given the possible regression I thought it was at least worth mentioning here.

[BartMassey]

Got the repo URL for mixy wrong above. Fixed now.

[alexcrichton]

Ah currently this library requires to always be built with optimization, I don't think it works unoptimized yet

[BartMassey]

Sorry, I kind of screwed up the bug report. Here's the source file in question, just so I'm sure we're talking about the same thing.

//! Copyright © 2016 Bart Massey
//! 
//! [This program is licensed under the "MIT License"]
//! Please see the file COPYING in the source distribution
//! of this software for license terms.
//!
//! Demonstrate making statically-linked rust
//! functions available to C.

#![crate_type="staticlib"]
#![feature(lang_items)]
#![no_std]
#![no_builtins]

#[no_mangle]
pub extern "system" fn rust_add(a: i32, b: i32) -> i32 {
    a + b
}

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

The only undefined symbol when this is compiled with checked arithmetic is panic.

I totally get that this might require a panic; if there's nothing that can be done about that, so be it. What would be nice would be some rustic way to map that panic to an abort. Right now I'm handling Rust's panic in the C code (see the just-updated repo), but that seems a bit special.

[alexcrichton]

@BartMassey have you tried compiling with -C panic=abort?

[BartMassey]

@alexcrichton Had forgotten -C panic=abort was a thing. Tried it. Doesn't change anything.

Interestingly, if I put in an explicit panic the rust code still tries to call core::panicking::panic even with optimization turned on. So I don't think -C panic=abort is doing anything.

I found this https://github.com/japaric/panic-abort/blob/master/src/lib.rs, but it doesn't seem to make panic call abort either, which is interesting.

Are the Rust name mangling rules documented somewhere? core::panicking::panic changes manglings in the trailing hex part depending on the weather, and I'd like to understand why.

[alexcrichton]

@BartMassey hm ok, I think I may be confusing myself. If you're using --emit obj then that's definitely going to hit undefined symbol errors because you need more than the object that rustc emits, but rather you'll also need libcore which defines these symbols.

The name mangling rules are currently an internal implementation detail and aren't a stable interface to rely on.

Do you have a script or such to reproduce this as well that I could help poke around in?

[BartMassey]

http://gitlab.com/BartMassey/mixy is what I'm currently playing with. It has rather a lot of branches, and is kind of a mess right now. Let me know what you want and I'll be happy to do some scripting or something for you.

It sounds like it's really my bug at this point, and maybe there's no clean way to work around it.

• I could turn off the arithmetic and array-bound checks when compiling in dev mode. This would make me sad but would be livable for this toy example.

• If I could get the compiler to emit its references to core::panicking::panic as unmangled panic, I could handle panics in C code.

• I could try to compile a version of libcore as a static library and depend on it. This kind of defeats the purpose of compiling with #[nobuiltins], though. I'm also afraid that I might end up with quite a bit of code bloat and references to the memory allocator.

• I could try to get the compiler to link against a hacked-up version of libcore/panicking.rs that is itself #[no-builtins]. I might try this shortly, but I'm not sure what's involved.

• Something else. There are rather a lot of possibilities.

Anyway, I should quit wasting your time with this. Thanks much for all your help and patience!

[alexcrichton]

@BartMassey sorry was away on vacation but am back now, in that example it's definitely invalid to use --emit obj, you'll want to try using --crate-type staticlib instead I believe

[alexcrichton]

I'm going to close this now because I think this is likely related to compilation issues with this library rather than the source itself.

[antoninhrlt]

After discovering issue #79, I tried rustc -O and it worked.

Thank you so much, you solved all my problems !!