Finish/polish user story for sources, binaries and symbols for debugging/profiling/tracing

[omajid]

Source-build helps everyone build a .NET SDK that's as feature-packed, stable and performant as the Microsoft-built SDK.

This issue is about tracking and finishing/polishing up the debugging, tracing and performance-measuring side of the user story. In other words, the user experience for users debugging, profiling, and tracing their applications with a source-built SDK should be as good as the story for Microsoft-built .NET.

This might require changes to the other tools in the ecosystem? If so, we should try and link to specific issues that are outside our domain for fixing.

Here are some things that where source-build has had issues in the past, compared to Microsoft's build of .NET

• Linking to .NET SDK/Runtime sources/repositories using sourcelink. In the past, we have seen tools like VSCode have trouble using this when trying to step into the Runtime code. Related issues include:
  • Enable sourcelink in source-build runtime#76685
  • Enable source-link in SourceBuild installer#14698
  • Add relevant SourceBuild tests for sourcelinks #3052
• Finding the necessary managed and unmanaged symbols. Tools like VSCode's C# debugger and dotnet-dump have had issues in the past when it comes to finding (or not finding) the necessary information. There's little clarity for users on how to fix/workaround those issues. Related issues include:
  • Add a test to check that all managed/unmanaged debug symbols are available #3462
  • The mscordbi.dll 6.0.922.42201 is missing from symbol servers.  runtime#75747 (closed because it was not actionable, underlying issues still exist)
  • Feature request: dotnet-symbol should acquire RedHat symbols diagnostics#1506
  • pdb files with .NET 8 #3547
  • dll files contain original/invalid path to pdb matching build directory #4011
• There's little documentation on what the folks building the .NET SDK can do (if anything) to verify/confirm that these things work correctly. Or what the current best workarounds for the current issues are.
• What's the story for end-users debugging .NET on ppc64le/s390x and other platforms not supported by Microsoft?

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichaelSimons]

[Triage] Ashita, Can you please drive the investigation on this?

[ashnaga]

Yes, I can take this forward.

[omajid]

I added an item about end-users (.NET application developers) who want to debug on non-Microsoft platforms (using a user-level debugging tool via something like VSCode). Currently, that doesn't work at all.

[omajid]

cc @aslicerh @janani66 @tmds @uweigand

[MichaelSimons]

[Triage] @ashnaga, is this something that you can work on in the Preview 7 timeframe?

[ashnaga]

I can pick up and determine the next steps.

[ashnaga]

@omajid
If can find, link the issues being mentioned in 1 & 2 point. I am searching to gather some example issues and not able find the ones specific to Linux builds.

[ashnaga]

Scoping the analysis to following problem statement -
In development state, if using Linux-Built SDK, then VS code C# debugger must pick .NET symbols from the disk. Symbols are placed alongside the binaries.
Note: Symbols to be downloaded by users via Package Manager

Will continue to research on solution for this one and moving the issue to be fixed in .NET 10 scope.