Support patchable-function-entry · Issue #704 · rust-lang/compiler-team (original) (raw)

Proposal

I am proposing that Rust support patchable-function-entry as present in clang and gcc. This feature is generally used to allow hotpatching and instrumentation of code.

What

patchable-function-entry provides configurable nop padding before function symbols and after function symbols but before any generated code. We refer to the former as prefix padding and the latter as entry padding. For example, if we had a function f with prefix set to 3 and entry to 2, we'd expect to see:

f_pad:
nop
nop
nop
f:
nop
nop
// Code goes here

f_pad here is not a real symbol or label, it is only inserted here for explanatory purposes. A __patchable_function_entries section will be added to the output object containing the addresses of each f_pad-like location in the object.

prefix and entry correspond to the LLVM attribute implementation.

The flag form instead uses nop_count and offset to match the clang and gcc flags for easier integration into build systems.

Why

The Linux kernel uses -fpatchable-function-entry heavily, including for ftrace and FINEIBT for x86. Today, enabling these features alongside Rust will lead to confusing or broken behavior (ftrace will fail to trace Rust functions when developing, FINEIBT will conflict with the kcfi sanitizer, etc.).

It also uses the clang and gcc attribute patchable_function_entry to disable this padding on fragile functions or those used for instrumentation. I have a companion RFC draft for this which covers both the flag described here and support for the attribute. This MCP is focused on just adding support for the flag, as this will unblock kernel work while we wait on RFC resolution for full support.

Integrating Rust code into this and other large projects which expect all native code to have these nop buffers will be made easier by allowing them to request the same treatment of native functions they get in C and C++.

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

File an issue describing the proposal.
A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
- Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.