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

Distribute macOS symbols as dSYM, not .dwarf #88286

Open
filipnavara opened this issue Jul 1, 2023 · 5 comments
Open

Distribute macOS symbols as dSYM, not .dwarf #88286

filipnavara opened this issue Jul 1, 2023 · 5 comments
Labels
area-Infrastructure enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@filipnavara
Copy link
Member

macOS tooling expects symbols to be distributed as .dSYM bundles created using dsymtool without the --flat parameter. The distribution using dSYM allows the lldb debugger, spindump, sample, and other tools to locate the symbols automatically (through Spotlight indexer with matches the symbols through UUID back to the original executable). This automatic symbol loading doesn't work for .dwarf files located next to the executable.

This makes debugging tools like ILCompiler particularly annoying. Profiling long compilations produces non-symbolicated traces which are hard to interpret.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Jul 1, 2023
@ghost
Copy link

ghost commented Jul 1, 2023

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

macOS tooling expects symbols to be distributed as .dSYM bundles created using dsymtool without the --flat parameter. The distribution using dSYM allows the lldb debugger, spindump, sample, and other tools to locate the symbols automatically (through Spotlight indexer with matches the symbols through UUID back to the original executable). This automatic symbol loading doesn't work for .dwarf files located next to the executable.

This makes debugging tools like ILCompiler particularly annoying. Profiling long compilations produces non-symbolicated traces which are hard to interpret.

Author: filipnavara
Assignees: -
Labels:

area-Diagnostics-coreclr

Milestone: -

@am11
Copy link
Member

am11 commented Jul 2, 2023

I think if we want to also ship .dSYM files, it will require coordinated effort. After the mechanical code changes in these places:

there might be additional work required in https://github.com/dotnet/diagnostics tools and https://github.com/dotnet/symstore (and the underlying blob storage).

@EgorBo
Copy link
Member

EgorBo commented Jul 2, 2023

I guess it should also help native profilers?

@filipnavara
Copy link
Member Author

I guess it should also help native profilers?

Yep. It applies to Instruments too.

@tommcdon tommcdon added enhancement Product code improvement that does NOT require public API changes/additions and removed untriaged New issue has not been triaged by the area owner labels Jul 5, 2023
@tommcdon tommcdon modified the milestones: 8.0.0, 9.0.0 Jul 5, 2023
@tommcdon tommcdon modified the milestones: 9.0.0, 10.0.0 Jul 23, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Infrastructure enhancement Product code improvement that does NOT require public API changes/additions
Projects
Status: No status
Development

No branches or pull requests

4 participants