Add unstable hotpatch flag to rustc

[nebulark]

This PR adds an unstable hotpatch flag, which ensures the first instruction of a function being two bytes long, otherwise inserting a nop. This is needed for code hotpatching (such as Live++ or Recode) tools to work, so they can provide very quick iteration cycles for development.

This uses a LLVM feature that is only implemented on x86/x86_64. On aarch64 this is not needed as there are no 1 byte instructions.

Hotpatching also requires a linker argument (e.g. functionpadmin on link.exe/lld), which ensures a minimum padding between functions. This can not implemented in rustc as this is linker specific. However, we do mark functions to be hotpatchable when using the hotpatch flag, as the link.exe/lld need it for their functionpadmin flag to work.

Typical usage with cargo for hotpatching the would be "RUSTFLAGS=-Z hotpatch -C link-arg=-functionpadmin". This currently only works on Windows due to linker support. But there should be nothing blocking other linkers to implement a flag similar to functionpadmin.

There is a similar flag "patchable-function-entry". The main difference is that hotpatch + functionpadmin, should leave functions that are already hotpatchable, an extremely common case, untouched. This reduces bloat, but requires linker support.

This is a first step to establish a proof of concept for rust-lang/compiler-team#745. The follow up step would be to add support for lld (or another linker) so this also works on linux.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

The run-make-support library was changed

cc @jieyouxu

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[jieyouxu]

This is waiting on the MCP rust-lang/compiler-team#745, right?

[nebulark]

The MCP is stuck due to missing linux support, due to missing linker support.

Current plan to get the MCP approved would be to:

1. Add this as an unstable flag, which as far as I was told does need need an MCP. So I am just doing it with this PR.
2. Add support to some Linux/ELF linker (probably LLD as the Window/COFF version already supports it)

With this there would be a proof of concept that works on linux and would unstuck the MCP.
Sorry if this caused any confusion.

[jieyouxu]

Ah okay, thanks for the clarifications!

[nebulark]

So ... I think we should remove the "S-waiting-on-MCP" tag then and put it back to waiting on review?
Or is there action needed from my side?

[jieyouxu]

This is waiting on the MCP because the MCP needs a second from a compiler team member. There's no action needed on your side.

[nebulark]

As far as I understood getting a second will only happen when I have a poc that works on linux.
I have been told adding an unstable flag should not require an MCP. Only stabilizing that flag does.
So I am trying to add the unstable flag now.
Please correct me if I understood anything wrong.

Again sorry for the confusion and thank you for your time!

[jieyouxu]

Let me go ask other compiler people about this and then get back to you.

[nikic]

As far as I understood getting a second will only happen when I have a poc that works on linux. I have been told adding an unstable flag should not require an MCP. Only stabilizing that flag does. So I am trying to add the unstable flag now. Please correct me if I understood anything wrong.

I think there's been a misunderstanding here. That was my opinion on the MCP, not on whether it needs an MCP. Unstable flags usually do go through an MCP.