-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: FuncForPC not returning correct function #58300
Comments
Change https://go.dev/cl/465076 mentions this issue: |
So if the PC of the first instruction is from an inlined function, returning the inner function seems reasonable? |
Yes, it is reasonable. But people are using |
Out of curiosity: what is the correct way to handle the result returned from |
@thediveo You could use it for, e.g., a sampling profiler. Just take the result of I think the more relevant question here is, what is the correct way to handle the result returned from |
@randall77 I probably didn't pose my question well: I wasn't asking for what I would need this information, as I've used it several times in the past in my own projects, such as a simplistic plugin-manager that derives package names from the caller's PC. What I was trying to ask is: is there a way to correctly detect the situation brought up in this issue in existing code and to properly handle it as to not take the inlined code as source, but the function where the inline code was put at the beginning? |
@thediveo Not with You can get the right answer, even in the presence of inlining, by using This issue is about getting the name of a function from a |
People are using this to get the name of the function from a function type: runtime.FuncForPC(reflect.ValueOf(fn).Pointer()).Name() Unfortunately, this technique falls down when the first instruction of the function is from an inlined callee. Then the expression above gets you the name of the inlined function instead of the function itself. To fix this, ensure that the first instruction is never from an inlinee. Normally functions have prologs so those are already fine. In just the cases where a function is a leaf with no local variables, and an instruction from an inlinee appears first in the prog list, add a nop at the start of the function to hold a non-inlined position. Consider the nop a "mini-prolog" for leaf functions. Fixes golang#58300 Change-Id: Ie37092f4ac3167fe8e5ef4a2207b14abc1786897 Reviewed-on: https://go-review.googlesource.com/c/go/+/465076 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: David Chase <drchase@google.com>
Change https://go.dev/cl/467977 mentions this issue: |
A 0-sized no-op shouldn't prevent us from detecting that the first instruction is from an inlined callee. Update #58300 Change-Id: Ic5f6ed108c54a32c05e9b2264b516f2cc17e4619 Reviewed-on: https://go-review.googlesource.com/c/go/+/467977 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Prints
where it should print
This happens because the first instruction of
g
is an instruction inlined fromf
.This came up recently because the scheduler change https://go-review.googlesource.com/c/go/+/270940 subtly changes the ordering, and line numbering, of assembly instructions at the start of functions.
The text was updated successfully, but these errors were encountered: