In debug mode, print a message for attempted unwind past FFI call
See https://github.com/rust-lang/rust/issues/47616 and https://github.com/rust-lang/rust/pull/46833 . Rust now generates an abort rather than attempting to unwind through an FFI call. In debug mode, could we generate a friendly error message explaining that, rather than just aborting? (In release mode we should continue to just abort.)
Hmm, but this raises questions w r t "where should it be printed?" "In no_std, can we even print things?"
diwic at 2018-02-01 18:13:46
no_stdstill haspanic_fmtand similar. (If a particular implementation of that throws away the message, that's fine.)Josh Triplett at 2018-02-01 18:19:14
Hmm, but calling
panic_fmtin that context will likely cause another panic (because panic_fmt is supposed to start a panic), which we will then catch in the same context, and then callpanic_fmton, which will cause an infinite loop?There might be a safe somewhere that causes such a double panic to abort the process, but I'm not sure we're then better off than we are today.
diwic at 2018-02-01 19:17:18
@diwic Hmmm, fair point. We need the "fmt" part of
panic_fmt, not the "panic" part. :)Josh Triplett at 2018-02-01 19:27:51
That would require adding a new lang item that would end up being required for essentially every binary. We already have quite a few cases where invoking UB will "just" crash with a SIGILL. I think it is better to just document common UBs that result in SIGILLs in a discoverable location and not sacrifice codegen quality or
#[no_std]usability.Simonas Kazlauskas at 2018-02-01 20:16:41
Triage: since this ticket has been filed, the abort behavior has been rolled back, and there have been attempts to make this defined behavior in some cases. There's no movement I'm aware of on this specific issue, though.
Steve Klabnik at 2019-11-22 04:54:46
This may be something @rust-lang/wg-ffi-unwind should look into, now that the behavior for
"C"is once again guaranteed to abort (in nightly).Kyle J Strand at 2021-03-13 00:08:28