-
Notifications
You must be signed in to change notification settings - Fork 591
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
Set Function.start_line when symbolizing #823
Comments
This seems reasonable to support and the change does look simple enough. I was going to ask whether the switch to hardcode The added benefit is that reading the JSON output is cleaner since this is clearly a machine-readable format. My only worry is whether this is going to be slower on large binaries - e.g. maybe LLVM is for any reason slower to produce JSON and parsing it would be added CPU time and RAM cost on the pprof side as well. It would be good to measure that at least in a couple of manual experiments. |
Sounds good, thanks! I'll be sure to measure the performance.
That change is just a hack. My machine didn't have |
Ack, thanks! Will review the PR when you have it (no rush, the pace is up to you). |
Please answer these questions before submitting your issue. Thanks!
What version of pprof are you using?
If you are using pprof via
go tool pprof
, what's yourgo env
output?If you run pprof from GitHub, what's the Git revision?
a5a03c7
What operating system and processor architecture are you using?
linux-amd64
What did you do?
If possible, provide a recipe for reproducing the error.
Attaching a profile you are trying to analyze is good.
Analyze a
perf.data
profile, automatically converted viaperf_to_profile
.What did you expect to see?
Function start lines are determined during symbolization.
What did you see instead?
No function start lines (
s=0
) in any of the locations.None of the symbolizers attempt to look up function start lines, so this isn't too surprising.
However, since LLVM 13,
llvm-symbolizer
has a JSON output (first mentioned in #606) which provides function start line. I prototyped this in prattmic@e80491e (without the necessary fallback for old versions), and it is pretty straightforward. I am happy to finish this up and turn into a real PR.My motivation here is using
perf.data
profiles for Go PGO.perf_to_profile
doesn't symbolize profiles, but pprof does, sopprof -proto perf.data > perf.pprof
is a convenient way to convert + symbolize. But Go PGO requires function start line, so today this isn't quite sufficient. We could of course write a separate symbolization tool, but IMO it seems reasonable for pprof to try to symbolize all of applicable proto fields.The text was updated successfully, but these errors were encountered: