Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add -Z instrument-mcount #57220

Merged
merged 1 commit into from
Dec 31, 2018
Merged

Add -Z instrument-mcount #57220

merged 1 commit into from
Dec 31, 2018

Conversation

quark-zju
Copy link
Contributor

This flag inserts mcount function call to the beginning of every function
after inline processing. So tracing tools like uftrace 1 (or ftrace for
Linux kernel modules) have a chance to examine function calls.

It is similar to the -pg flag provided by gcc or clang, but without
generating a __gmon_start__ function for executables. If a program
runs without being traced, no gmon.out will be written to disk.

Under the hood, it simply adds "instrument-function-entry-inlined"="mcount"
attribute to every function. The post-inline-ee-instrument LLVM pass does
the actual job.

This flag inserts `mcount` function call to the beginning of every function
after inline processing. So tracing tools like uftrace [1] (or ftrace for
Linux kernel modules) have a chance to examine function calls.

It is similar to the `-pg` flag provided by gcc or clang, but without
generating a `__gmon_start__` function for executables. If a program
runs without being traced, no `gmon.out` will be written to disk.

Under the hood, it simply adds `"instrument-function-entry-inlined"="mcount"`
attribute to every function. The `post-inline-ee-instrument` LLVM pass does
the actual job.

[1]: https://github.com/namhyung/uftrace
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 30, 2018
@estebank
Copy link
Contributor

@bors r+

CC @rust-lang/compiler

@bors
Copy link
Contributor

bors commented Dec 31, 2018

📌 Commit 31a5066 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 31, 2018
@bors
Copy link
Contributor

bors commented Dec 31, 2018

⌛ Testing commit 31a5066 with merge 6efaef6...

bors added a commit that referenced this pull request Dec 31, 2018
Add `-Z instrument-mcount`

This flag inserts `mcount` function call to the beginning of every function
after inline processing. So tracing tools like uftrace [1] (or ftrace for
Linux kernel modules) have a chance to examine function calls.

It is similar to the `-pg` flag provided by gcc or clang, but without
generating a `__gmon_start__` function for executables. If a program
runs without being traced, no `gmon.out` will be written to disk.

Under the hood, it simply adds `"instrument-function-entry-inlined"="mcount"`
attribute to every function. The `post-inline-ee-instrument` LLVM pass does
the actual job.

[1]: https://github.com/namhyung/uftrace
@bors
Copy link
Contributor

bors commented Dec 31, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: estebank
Pushing 6efaef6 to master...

@bors bors merged commit 31a5066 into rust-lang:master Dec 31, 2018
@nagisa
Copy link
Member

nagisa commented Dec 31, 2018

Is it known that all the tools use specifically the mcount function name? A codegen test would’ve been nice as well.

@quark-zju
Copy link
Contributor Author

quark-zju commented Dec 31, 2018

Good question. clang -pg defaults to mcount but platforms can override it. The rule seems rather complicated. I think a complete solution would be platform-dependent. I'll add a comment, and try to add a test.

EDIT: uftrace also uses different names on different platforms.

@eddie9712
Copy link

eddie9712 commented Jan 17, 2022

Hi all, I have tried the "-Z instrument-mcount" with rustc compiler (rustc 1.60.0-nightly (bd3cb5256 2022-01-16)). However, I didn't get any mcount function inserted in my executable file. Is the "-Z instrument-mcount" still supported ?

@dwlsalmeida
Copy link

@eddie9712 same here!

@honggyukim
Copy link

Hi, @quark-zju already analyzed this problem before at namhyung/uftrace#1392 (comment). There must be some changes in LLVM 13. @tlambertz found a workaround at namhyung/uftrace#1392 (comment) as follows.

rustc +nightly -Zinstrument-mcount -C passes="ee-instrument post-inline-ee-instrument" main.rs

For now, we have to add -C passes="ee-instrument post-inline-ee-instrument" along with -Zinstrument-mcount until LLVM fixes this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants