-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
required for panic=abort
#38281
Comments
STR
Bisecting: BAD: GOOD: AFAICT, the difference is that
Changing the #[lang = "panic_fmt"]
-extern "C" fn panic_fmt() -> ! {
+pub extern "C" fn panic_fmt() -> ! {
loop {}
}
cc @michaelwoerister this may have been caused by #38117 |
@japaric That analysis looks pretty correct to me. I suspect that adding @brson, @alexcrichton: I guess lang-items should always have external linkage? |
@michaelwoerister yeah unfortunately things like If it's not already |
@alexcrichton OK.
Also, should these symbols be re-exported from (c)dylibs? Probably not, right? |
Yeah ideally we wouldn't export |
Sorry to be annoyning but a few people that work with the |
@japaric Have you tried if adding #[no_mangle] helps? |
@michaelwoerister |
The #[no_mangle] attribute just prevents the compiler from hiding the symbol. The compiler generally will try to hide as many symbols as possible because it can make for smaller and faster code and allows LLVM to do more optimizations. The algorithm that determines what to hide has become a little more aggressive recently, which is why this pops up now. So there is a workaround (i.e. #[no_mangle]) but it's not quite ideal. I'd rather that the compiler knows about these special symbols (or that we require, with a lint for example, that this lang-item and maybe others, have the right name and annotations). |
I know what |
Oh, that's because this already has some special handling in the compiler. As far as I can tell, no matter what actual name the function has, if it is marked with #[lang = "panic_fmt"] then it will be assigned "rust_begin_unwind" as symbol name. It's a bit strange. |
@michaelwoerister |
That works, thanks. Is that how this lang item is supposed to be used from now on? Or will the no |
@japaric I think that's pretty much up to the tools and compiler teams to decide. I personally don't mind giving lang-items special treatment, since that allows us to later not require #[no_mangle] or even that they are exported. |
(cherry picked from commit 081105bbb60e1c76f222a6c34baac4eec0c83846) (cherry picked from commit 1acc1ff5806f2fa101f726644d258eb4e4543540)
(cherry picked from commit 081105bbb60e1c76f222a6c34baac4eec0c83846) (cherry picked from commit 1acc1ff5806f2fa101f726644d258eb4e4543540)
This was pretty smooth and painless, mostly fixing up global variable names to be all caps b/c that's caught now and a few structures got smaller (whoo!) One gotcha, the `#[lang=panic_fmt]` now requires you to also add a `#[no_mangle]` directive, otherwise the symbol will be dropped and you'll get an undefined reference to `rust_begin_unwind` (which is what our `panic_fmt` function gets silently renamed to courtesy of the magic of `#[lang=panic_fmt]`). More info at rust-lang/rust#38281 An unresolved mystery, imix currently gives this warning: warning: function panic_fmt is marked #[no_mangle], but not exported, #[warn(private_no_mangle_fns)] on by default --> src/io.rs:40:1 | 40 | pub unsafe extern "C" fn panic_fmt(args: Arguments, file: &'static str, line: u32) -> ! { | ^ Now, of course, removing no_mangle will result in the undefined reference as described above, with it this at least compiles, unclear what's different about imix than the other platforms that don't throw this warning. Run-tested on hail. Compile-tested on every other platform.
* Import compiler builtin crate to fix issue with _umod and _udiv * Trim unnecessary Makefile variables and flags * Keep the BLOCK and ALIGN commands in linker.ld for now * Fix linking error `undefiend reference to rust_begin_unwind` * `panic_fmt` was mangled through optimization * `panic_fmt` becomes `rust_begin_unwind` * Solution: add `#[no_mangle]` before `panic_fmt` * [Rust Issue](rust-lang/rust#38281)
@alexcrichton @michaelwoerister Could someone clarify how to fix this for stable builds? |
@urschrei you may be running into #18807, can you test the workaround mentioned? |
@alexcrichton Just adding a spare function still fails with the same error. I assume adding it to |
Oops, turns out it does have to be in |
This was pretty smooth and painless, mostly fixing up global variable names to be all caps b/c that's caught now and a few structures got smaller (whoo!) One gotcha, the `#[lang=panic_fmt]` now requires you to also add a `#[no_mangle]` directive, otherwise the symbol will be dropped and you'll get an undefined reference to `rust_begin_unwind` (which is what our `panic_fmt` function gets silently renamed to courtesy of the magic of `#[lang=panic_fmt]`). More info at rust-lang/rust#38281 An unresolved mystery, imix currently gives this warning: warning: function panic_fmt is marked #[no_mangle], but not exported, #[warn(private_no_mangle_fns)] on by default --> src/io.rs:40:1 | 40 | pub unsafe extern "C" fn panic_fmt(args: Arguments, file: &'static str, line: u32) -> ! { | ^ Now, of course, removing no_mangle will result in the undefined reference as described above, with it this at least compiles, unclear what's different about imix than the other platforms that don't throw this warning. Run-tested on hail. Compile-tested on every other platform.
…t#38281 (comment) Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>
Ping from triage! I attempted to update the code: > cat .\src\main.rs
#![feature(panic_handler)]
#![no_main]
#![no_std]
#[no_mangle]
pub fn _start() -> ! {
panic!()
}
use core::panic::PanicInfo;
#[panic_handler]
#[no_mangle]
pub fn panic(_info: &PanicInfo) -> ! {
loop { }
} but I got a different error, possibly because I'm on windows > cargo rustc -- -C link-arg=-nostartfiles
Compiling app v0.1.0 (file:///C:/Users/steve/tmp/app)
error: linking with `link.exe` failed: exit code: 1561
|
= note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\steve\\tmp\\app\\target\\debug\\deps\\app-3187309a36d3b090.1aq5w1s18bk2pb4a.rcgu.o" "/OUT:C:\\Users\\steve\\tmp\\app\\target\\debug\\deps\\app-3187309a36d3b090.exe" "/OPT:REF,NOICF" "/DEBUG" "/NATVIS:C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\etc\\libcore.natvis" "/LIBPATH:C:\\Users\\steve\\tmp\\app\\target\\debug\\deps" "/LIBPATH:C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-68de561760a7c421.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-a0d3327a110151c3.rlib" "-nostartfiles"
= note: LINK : warning LNK4044: unrecognized option '/nostartfiles'; ignored
LINK : fatal error LNK1561: entry point must be defined
error: aborting due to previous error
error: Could not compile `app`. I tried to figure out the equivalent msvc option, but it wasn't clear... |
Instead of defining a lang item, the So this issue was superseded by #51342, which was fixed. Therefore I'm going to close this issue. |
…t#38281 (comment) Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>
Since a few nightlies, the compiler requires a
rust_begin_unwind
symbol again even though myno_std
crate usespanic=abort
:The big problem is that defining a
rust_begin_unwind
function in Rust gives an error, too:I only works if I add a
rust_begin_unwind
function to a C file that is linked with the Rust crate.The text was updated successfully, but these errors were encountered: