-
Notifications
You must be signed in to change notification settings - Fork 132
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Resolving framework symbols #1564
Comments
(Context I grabbed from the doc to get myself up to speed:) This is about perf tracing the shared framework (runtime) we crossgen during source-build. Not apps that are crossgen'd as part of runtime-dependent or self-contained publish.
The clear way forward here is #1215. There's no obvious place to stick it based on the Microsoft build's current behavior. (Not that it can't be unique to source-build... but would be nice not to have to invent something.)
Filed #1565 for this. I think it would be useful to get this sentence clearer from that doc:
Why "need"? Is there something about perf tracing where the data doesn't exist, e.g. it's app-specific in some way? Or is it just because the symbols aren't generally accessible, so we can provide PDBs instead if we've managed to keep track of them? (I think I'm basically stating the same question here. 😛) |
When the runtime is first deployed onto a machine the symbolic data that maps RVAs to method names for R2R code is present inside the R2R images, however the profiling tools don't understand how to directly parse the R2R format to extract the data. The tools do understand a textual format called perfmap so the crossgen tool is used to read the RVA->method name map from the R2R format and transcode it to the textual perfmap format. If you skip this step then the IPs for code loaded from R2R images will not be resolvable in the trace. |
Thanks @dagood !
@noahfalk thank you for chiming in. I wonder what is the proper way forward here:
|
The first option there, including crossgen with source-build, is the one I'd suggest exploring first. Its possible further research would discover a problem, but two things that make it appealing to me:
Also to cover all the bases I guess I should ask, is it reasonable that perf could understand enough of the R2R binary format that we didn't need to transcode it? For customers I suspect it would be ideal if no pre-processing was needed, but I don't know if this is something the maintainers of perf would consider? |
I'm not a |
Thanks @tdms! @davidwr @jkotas @MichalStrehovsky - What would you guys think about having an external tool (perf) understand enough of the R2R format that it could decode symbolic information directly? The upside is that it makes .NET feel more platform native, the downside is that it increases our compat burden. I don't know how much churn you were anticipating the format to have in the future? |
I do not think that the format is complete and stable enough to do that. |
I think that the right options for this are:
|
I agree with @jkotas that the options he specifies are good choices. FWIW, I intend to update |
Thanks all!
Is this a task that has pre-existing priority around it, or we'd need to drive it based on the demands of the perf scenario? I recalled hearing desire to use platform native formats over the years, but I hadn't gotten the impression it was something where active progress was occuring (or would be likely to occur in the near future).
My primary concern (if I am remembering correctly) is that it does a flushed file write on every R2R method load which probably distorts startup a fair amount. Am I more worried about it than I should be or any thoughts on how we ameliorate it? |
The flushing was removed to improve perf. dotnet/runtime#229 |
This is not scheduled at the moment, but I can imagine it getting prioritized at some point for one or more of: performance, diagnostics, security, be Linux native. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
As described in https://github.com/dotnet/runtime/blob/master/docs/project/linux-performance-tracing.md, to do performance tracing and resolve framework symbols, you should
For source-build, the simplest may be to include
crossgen
?This could be included in the runtime package, or maybe as part of a debug symbols package.
In our source-build .NET Core 3.1 we include
pdb
files forMicrosoft.NETCore.App
dlls.I'm not sure what tools can use these
pdb
files? and how they relate to needing, or not needingcrossgen
?Also, we don't seem to have
pdb
files forMicrosoft.AspNetCore.App
, so we may be missing debug info for ASP.NET framework?cc @brianrob @noahfalk @omajid @dagood @crummel @dseefeld
The text was updated successfully, but these errors were encountered: