The posture towards symbols on different platforms is quite interesting to see: I think all major OSes strip their binaries, but Microsoft provides them as a separate download and Linux of course has *-dbg packages and the upcoming debuginfod. In comparison, macOS is truly an infuriating platform because Apple strips their code and recommends others do so to (it's done automatically as part of deployment postprocessing) for size improvements but because Apple and third party developers are sold on the FUD that providing symbols will ruin their business nobody ever provides them separately. (Aside: if you ship software and run any sort of stripping/minification on it and want to claim it is for the size benefits exclusively, you are honor bound to provide the information you removed, whether that is DWARF or a source map. No exceptions. Personally, I consider this important enough to not do these things at all, but I get it if you fall on the other side of the "size vs. inspectability" spectrum–you just need to also provide the stuff you throw away if you don't want to be annoying.)<p>More on point, though, I can see both Windows and Linux getting the experience of finding debug symbols to be pretty good™–but for the same reasons I cannot see macOS getting this unless attitudes change. Apple of course runs this internally and "forgets" to share the scripts with us, and I have heard of other companies doing similar things, but I don't see any sort of unified effort in this area at all :(
Another related capability you can use when indexing PDBs for a build is the "source server". It tags the pdb with source control commands to retrieve the source revision at the time of building. Enable the feature in the debugger and you don't have to manually retrieve the right source code when you get a crash dump from a customer for an old version of your software.<p>It embeds executable source control commands in the PDB so you need to make sure you know where your PDBs come from.<p>Reference:<a href="https://docs.microsoft.com/en-us/windows/win32/debug/source-server-and-source-indexing" rel="nofollow">https://docs.microsoft.com/en-us/windows/win32/debug/source-...</a>
For those wondering, “symbols” refers to auxiliary debugging information for binaries: <a href="https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/symbols-and-symbol-files" rel="nofollow">https://docs.microsoft.com/en-us/windows-hardware/drivers/de...</a>
I really, really, really wish other platforms would embrace the same concept. We (Sentry) have added support for the same concept for other platforms but sadly there is not a lot of uptick in the general Linux community to start producing indexed debug symbols repositories.<p>Here are all the formats for symbol servers we are currently support for Linux/Mac and Windows: <a href="https://getsentry.github.io/symbolicator/advanced/symbol-server-compatibility/" rel="nofollow">https://getsentry.github.io/symbolicator/advanced/symbol-ser...</a>
One development since that article was written is Source Link:<p><a href="https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/sourcelink" rel="nofollow">https://docs.microsoft.com/en-us/dotnet/standard/library-gui...</a><p>It makes it easy to publish symbols for you .NET nuget packages. When debugging, Visual Studio will automatically download these symbols and the source code from GitHub, so you can easily step through third party code.<p>There is also support for C++
Having worked with Citrix a lot, it was always nice that both Microsoft and Citrix provide symbol servers. Despite not having any kernel debugging experience at all, it was always worthwhile setting up WinDbg with those two symbol paths to do some drive-by diagnostics of any blue-screen crash dumps. More than half the time this would instantly identify the "culprit".