Tracking Issue for the x86 `ud2` intrinsic

[Amanieu]

Feature gate: #![feature(stdarch_x86_ud2)]

This is a tracking issue for an x86 intrinsic for the ud2 instruction.

Public API

// core::arch::{x86,x86_64}

fn ud2() -> !

Steps / History

• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[jyn514]

Hmm, don't we already expose this as core::intrinsics::abort? What advantage does the new function have?

[Amanieu]

I'm just adding tracking issues to all unstable functions in stdarch.

For this one specifically I'd be in favor of just removing it. But let's wait for me to actually finish tagging everything with tracking issues first.

[asquared31415]

core::intrinsics::abort doesn't guarantee that it will become a UD2, or have any specific codegen at all, even on a particular arch, it's implementation defined.

On Unix, the process will probably terminate with a signal like SIGABRT, SIGILL, SIGTRAP, SIGSEGV or SIGBUS. The precise behaviour is not guaranteed and not stable.

Since this function is simply exposing a instruction, we could remove in in favor of asm!. This function is perhaps convenient, since it returns a ! and is less to write. But I think that since it's one instruction, the stable asm! exposes more than enough.

Side note: if we keep this function, does it need a safety requirement along the lines of "there must not be a UD2 handler that returns execution", since it's defined as -> !?

[Amanieu]

@rfcbot fcp close

Let's remove this in favor of asm!.

[rfcbot]

Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[chorman0773]

if we keep this function, does it need a safety requirement along the lines of "there must not be a UD2 handler that returns execution", since it's defined as -> !?

A handler is not a problem here, since the C Standard on signal function states

If the user defined function returns when handling SIGFPE, SIGILL or SIGSEGV, the behavior is undefined.

However, you could SIG_IGN SIGILL, which is problematic. On posix, you could also block the signal.

As sigaction is MT-safe, such a safety requirement is unsatisfiable in a multithreaded program.

[asquared31415]

This function is in core::arch::x86_64 and on certain x86_64 targets, such as no-OS targets, handling a #UD is not only allowed, but expected. It's possible to write a #UD interrupt handler that returns as if it were a no-op. So there are external requirements on the state of things for this signature to be correct.

Not that it matters anymore, since it's being removed.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔