Use libc::abort, not intrinsics::abort, in rtabort!

[lambda]

intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.

For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.

On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.

This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!

cc #31273
cc #31333

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[lambda]

As discussed in #31333, it may be more appropriate to abort using SIGABRT rather than SIGILL. As @brson said:

My preference is for all aborts to be the same, and would prefer this to be an rtabort!. If it would be more proper to terminate with SIGABORT than SIGILL let's do that for all aborts, not just this one (but in a separate PR).

This only turns rtabort! into SIGABRT, and only on Unix; on Windows, @alexcrichton mentioned that we want to avoid the C runtime, and it seems like less of a win there. Also, I believe that we don't have the ability to use libc::abort in lower-level libraries that call intrinsics::abort, so that remains implemented as before.

[retep998]

The proper mechanism on Windows is actually __fastfail which is an intrinsic https://msdn.microsoft.com/en-us/library/dn774154.aspx

[retep998]

Alternatively we can call RaiseFailFastException which is a full function call rather than a simple instruction.

[alexcrichton]

lgtm

[lambda]

@retep998 Yeah, looks like one of those might be appropriate. Since I don't have a Windows box and I don't know how the current mechanism or those behave on Windows, it's probably more appropriate for someone else who does have such access to send a patch for switching to those on Windows if appropriate.

[retep998]

Here is the Windows implementation.

unsafe{asm!("int $$0x29"::"{ecx}"(7)::: volatile);// 7 is FAST_FAIL_FATAL_APP_EXIT
std::intrinsics::unreachable();}

[brson]

@bors r+ I'll submit a windows implementation in a bit.

[bors]

📌 Commit de250e5 has been approved by brson

[brson]

@bors r- I want to wait until we decide on #31519

[alexcrichton]

Hey @lambda, sorry for the delay! With the landing of #32900 we're already starting to diverge in terms of what abort means on each platform, so I think it's fine now to land this for the Unix side of things and then we can fixup the Windows side later. It seems like it's actually somewhat difficult to find a canonical way on Windows that indicates "the runtime wanted to abort" that works everywhere!

Would you be ok updating this patch with two pieces?

• A comment indicating why Unix/Windows differ
• A bit of a refactoring to share at least the dumb_print code and only differ in the abort code

[lambda]

@alexcrichton Should be done in my most recent push.

I also rebased the Windows patch from @brson from #31519 in another branch in my repo, in case we want to also apply that. I could push that to this PR if we want to merge both at once, or I could push that separately after this lands. I'm reasonably convinced by the arguments from @retep998 that that's the right thing to do on Windows, but I'm not a Windows user and it's been a while since I've done serious Windows development, so I will defer to those with more experience on that platform.

[retep998]

I'm still of the opinion that __fastfail is the better choice for Windows because on newer Windows it causes the process to die loudly with an uncatchable exception, and on older Windows it is equivalent to intrinsics::abort in that it still causes an exception just with a different error code.

[alexcrichton]

@bors: r+ cfc3865

Thanks @lambda! Sending #31519 as a new PR also seems fine to me.

[bors]

⌛ Testing commit cfc3865 with merge 6e45564...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild