-
Notifications
You must be signed in to change notification settings - Fork 4.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
Distribute macOS symbols as dSYM, not .dwarf #88286
Comments
Tagging subscribers to this area: @tommcdon Issue DetailsmacOS tooling expects symbols to be distributed as .dSYM bundles created using This makes debugging tools like ILCompiler particularly annoying. Profiling long compilations produces non-symbolicated traces which are hard to interpret.
|
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). |
I guess it should also help native profilers? |
Yep. It applies to Instruments too. |
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
macOS tooling expects symbols to be distributed as .dSYM bundles created using
dsymtool
without the--flat
parameter. The distribution using dSYM allows thelldb
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.
The text was updated successfully, but these errors were encountered: