Introduce a way to opt-out of source info in Diagnostics StackFrame

[eerhardt]

The source line info support for System.Diagnostics.StackTrace/StackFrame comes with a noticeable cost for workloads which are size sensitive and don't contain PDB information anyway.

With change #32023, we added a PreserveDependency attribute here:

runtime/src/coreclr/src/System.Private.CoreLib/src/System/Diagnostics/StackFrameHelper.cs

Lines 87 to 93 in 768c6fc

	// This is necessary because linker can't add new assemblies to the closure when recognizing Type.GetType
	// so the code below is actually recognized by linker, but fails to resolve the type since the System.Diagnostics.StackTrace
	// is not always part of the closure linker works on.
	// PreserveDependencyAttribute on the other hand can pull in additional assemblies.
	[PreserveDependency("GetSourceLineInfo", "System.Diagnostics.StackTraceSymbols", "System.Diagnostics.StackTrace")]
	[PreserveDependency(".ctor()", "System.Diagnostics.StackTraceSymbols", "System.Diagnostics.StackTrace")]
	internal void InitializeSourceInfo(int iSkip, bool fNeedFileInfo, Exception? exception)

As noted in the PR, the change added ~200K to the "Console Hello World" app, bringing in the following assemblies, which were not needed before:

We should consider adding a feature switch (dotnet/designs#99) or similar functionality to allow app developers to opt-out of this behavior.

cc @vitek-karas @jkotas @stephentoub @marek-safar

[danmoseley]

Added to Linker project which I guess is how we keep track of all such work.

[marek-safar]

I don't think this should be feature switch in the design sense as above but illinker property which controls debugging support.

[krwq]

@eerhardt I'm marking this as 5.0 so it doesn't disappear from the radar, please change milestone to Future if you feel like this is not important for 5.0

[eerhardt]

@marek-safar @vargaz - I just discovered that this code isn't used on Mono's CoreLib. Instead, I see that Mono has a native C reader for PPDBs.

runtime/src/mono/netcore/System.Private.CoreLib/src/System/Diagnostics/StackFrame.Mono.cs

Lines 51 to 53 in b24e9cd

	[MethodImplAttribute(MethodImplOptions.InternalCall)]
	private static extern bool get_frame_info(int skipFrames, bool needFileInfo,
	out MethodBase method, out int ilOffset, out int nativeOffset, out string file, out int line, out int column);

Is this the long-term solution for Mono? I'm wondering how important it is for us to solve the above Diagnostics StackFrame issue in .NET 5. If Blazor isn't going to be affected by it, it might not be critical to solve.

[marek-safar]

I think we'll investigate using managed ppds reader but we might not be able to do it for .NET5 but long term this looks attractive to me.

#32023 is not relevant to size sensitive workloads and will become only once the logic is moved to shared SPC. What is however still relevant to us is the "forced" StackTraceSymbol persistence in S.D.S which I'm not sure why it's still there

[eerhardt]

What is however still relevant to us is the "forced" StackTraceSymbol persistence in S.D.S which I'm not sure why it's still there

I'll look into removing it today. Thanks for the pointer.

[eerhardt]

This is not necessary for Blazor WASM in 5.0. Moving to 6.0.

[eerhardt]

Moving to 'Future' as this isn't high priority for 6.

[jkotas]

This should be tagged on StackTraceSupport introduced in #88235 .