RFC: Add compiler support for instrumenting functions#3917
RFC: Add compiler support for instrumenting functions#3917pmur wants to merge 4 commits intorust-lang:masterfrom
Conversation
text/0000-instrumented-functions.md
Outdated
| * [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). |
There was a problem hiding this comment.
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
added
T-lang
| ## Prior art | ||
| [prior-art]: #prior-art |
There was a problem hiding this comment.
How does this related to RFC patchable-function-entry by @maurer ?
There was a problem hiding this comment.
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.
With the current instrumentation frameworks, I don't think there is benefit to fine grain controls. I have simplified the attribute to "on" and "off". XRay has some creative options, but fine grain control of entry and exit instrumentation insertion probably isn't useful.
|
I've also created a draft PR for implementation, rust-lang/rust#153742. |
|
I think the RFC needs some more clarity on why we want/need to support all of these instrumentation options. In particular, for mcount I'm not sure we should be moving towards stabilization, rather than moving towards removal. The RFC mentions two potential use cases, one being gprof (which, I think, has been pretty much completely superseded by other profiling tools nowadays) and the other kernel ftrace. Ftrace also supports using patchable function entries instead, and as far as I know, that is the generally preferred mechanism. I think some legacy architectures (most of which rustc doesn't even support) use mcount because patchable function entry is not implemented for them -- but that's probably better addressed by implementing it, if anyone actually cares. |
5 participants
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