Support .NET SourceLink

[vaind]

Portable PDBs may come with a SourceLink. It would be great if this could be automatically used to produce "Source Context" for debug files uploaded to Sentry as well as those fetched from remote debug-info servers

Resources

• https://devblogs.microsoft.com/dotnet/producing-packages-with-source-link/
• When sourcelink data is available send with event sentry-dotnet#400
• Support for Source Context sentry-dotnet#646
• https://github.com/dotnet/runtime/blob/main/docs/design/specs/PortablePdb-Metadata.md#source-link-c-and-vb-compilers

PR #734 brings the CustomDebugInformationIterator that can be used to filter the SourceLink info by specifying its "kind" as a filter: Kind: {CC110556-A091-4D38-9FEC-25AB9A351A6A}. You can see how this is done in EmbeddedSourceIterator.

Therefore, exposing a public iterator in symbolic-ppdb should be fairly simple. On the other hand, something will probably need to happen in symbolicator? Can someone pls fill in the blanks what that would be to make this work? Are we also going to need changes in the UI?

cc @Swatinem

[Swatinem]

Symbolic is agnostic to where to fetch data from. You could expose just the raw sourcelink.

Symbolicator currently does symbolication and source context application as two different phases, first fetching debug files to symbolicate. Then fetch all relevant source bundles to apply source context.

Here is a link to the actual JSON file/format that is embedded in the portable pdb:
https://github.com/dotnet/designs/blob/main/accepted/2020/diagnostics/source-link.md#source-link-json-schema

Looks like this is a per-sourcefile attribute. Which means we could probably resolve the url to the source file in the symbolication step, then later when we iterate over all the frames to know which source bundles to fetch, we can prefer the source file url if there is one, and fetch that in parallel with all the other source bundles.

As this is per-source-file rather than per-module, I’m not quite sure where/how we should expose the various download statuses and errors. Caching might also be an open question.
^ Especially this part may need some more discussion also from the product perspective, as it does have UI implications, etc.

I believe implementation-wise this would be quite straight forward actually.

[mattjohnsonpint]

This would be very nice.

Just to point out, my TimeZoneConverter library we've been testing with is set up for SourceLink (here), and you can see the relevant details in the NuGet Package Explorer:

https://www.nuget.org/packages/TimeZoneConverter

Looks like each assembly has the links to its sources. The repo url and hash are also available on assembly attributes and in the package metadata itself.

[vaind]

RFC: getsentry/rfcs#74