Skip to content

RFC: Add compiler support for instrumenting functions#3917

Open
pmur wants to merge 2 commits intorust-lang:masterfrom
pmur:murp/instrumented-functions
Open

RFC: Add compiler support for instrumenting functions#3917
pmur wants to merge 2 commits intorust-lang:masterfrom
pmur:murp/instrumented-functions

Conversation

@pmur
Copy link

@pmur pmur commented Feb 10, 2026

This RFC proposes to add support for instrumenting function calls using mcount fentry or xray, and adding a new builtin attribute to toggle instrumentation.

Today, mcount and xray enjoy experimental support, but I was unable to find any RFC proposing their inclusion.

Rendered

* [XRay](https://llvm.org/docs/XRay.html), an LLVM project to instrument both entry and exit of functions,
with dynamic enablement.

These features are all very similar, are effectively mutually exclusive (e.g., mcount and fentry).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
These features are all very similar, are effectively mutually exclusive (e.g., mcount and fentry).
These features are all very similar, and are effectively mutually exclusive (e.g., mcount and fentry).


### Language additions

A single builtin attribute, `instrument_fn`, will be added. It will be applied to functions and methods
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe there should be #[instrument_fn = "off"] or similar to opt out of all function instrumentation, not just entry/exit (you mentioned loop instrumentation earlier), that would be useful when implementing the instrumentation function to avoid recursively calling itself.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For usability, that seems nice for most common cases. I'll add it.

As for ignore-loops, it is an xray option to modify its heuristics for deciding to whether to instrument the function. I wonder if there is a case where you want to instrument more than *logues, but less than every basic block.

@ehuss ehuss added T-lang Relevant to the language team, which will review and decide on the RFC. T-compiler Relevant to the compiler team, which will review and decide on the RFC. labels Feb 10, 2026
Comment on lines +157 to +158
## Prior art
[prior-art]: #prior-art
Copy link
Member

@Darksonn Darksonn Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this related to RFC patchable-function-entry by @maurer ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For linux ftrace, both provide similar features. Though, x86-64 seems to support both, and some distros use both. I am curious why.

For using existing instrumentation frameworks like gprof or xray, there are more expectations beyond inserting and tracking nops at entry.

* Add `#[instrument_fn = "off"]` form.

* s/linux/Linux/ when used as a proper noun.

* Add prior art paragraph about patachable-function-entries rfc.

* Clarify `ignore-loops` xray option.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-lang Relevant to the language team, which will review and decide on the RFC.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants