[browser][CoreCLR] Trimming feature System.Diagnostics.StackTrace.IsLineNumberSupported

[pavelsavara]

• Added[FeatureSwitchDefinition("System.Diagnostics.StackTrace.IsLineNumberSupported")]
• triggered by <StackTraceLineNumberSupport>false</StackTraceLineNumberSupport>
• wich is set by default in WASM for Release

saves 214KB of uncompressed IL from hello world

[Copilot]

Pull request overview

This PR optimizes browser/WASM builds by disabling stack trace file information (filename, line number, column number) collection for the TARGET_BROWSER platform. This saves approximately 214KB of uncompressed IL from hello world applications.

Changes:

• Guard file info population code in StackFrameHelper.InitializeSourceInfo with #if !TARGET_BROWSER
• Guard static reentrancy tracking fields used only for file info processing
• Guard file info field assignments in StackFrame constructors
• Add CA1822 pragma suppression for InitializeSourceInfo (needed because the method doesn't use instance state on browser)

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/coreclr/System.Private.CoreLib/src/System/Diagnostics/StackFrameHelper.cs	Guards file info processing logic and reentrancy tracking with #if !TARGET_BROWSER, adds CA1822 suppression
src/coreclr/System.Private.CoreLib/src/System/Diagnostics/StackFrame.CoreCLR.cs	Guards file info field assignments in constructor and BuildStackFrame method with #if !TARGET_BROWSER

[pavelsavara]

We can eventually hide this behind some feature flag. So that in debug build, we would have full fidelity stack trace with line numbers.

There is System.Diagnostics.StackTrace.IsSupported but it does something else related to DiagnosticMethodInfo

Could the same flag be used here ? @jkotas

[dotnet-policy-service]

Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar
See info in area-owners.md if you want to be subscribed.

[jkotas]

Is the stack trace line number support unconditionally disabled in Mono Browser today? Trying to understand whether we need extra work to get CoreCLR to parity with Mono Browser.

Could the same flag be used here?

The existing msbuild property that does the same thing is StackTraceLineNumberSupport. It is NAOT-specific and it was introduced just recently. We would want to use the same one here.

[steveisok]

Is the stack trace line number support unconditionally disabled in Mono Browser today? Trying to understand whether we need extra work to get CoreCLR to parity with Mono Browser.

Not 100% sure, but I don't think we do anything special. If

runtime/src/mono/mono/metadata/mono-debug.c

Line 799 in 46c884e

mono_debug_lookup_source_location (MonoMethod*method, guint32address, MonoDomain*domain)

returns NULL, it won't display file info.

The existing msbuild property that does the same thing is StackTraceLineNumberSupport. It is NAOT-specific and it was introduced just recently. We would want to use the same one here.

I was wondering the same thing. And perhaps apply it in https://github.com/dotnet/runtime/blob/5dd95537d5faa20e8baed719e9f5f18d5f29494c/src/libraries/System.Private.CoreLib/src/System/Diagnostics/StackTrace.cs instead of the CoreCLR specific file.

[pavelsavara]

Is the stack trace line number support unconditionally disabled in Mono Browser today?

Mono doesn't use StackFrameHelper at all.
It doesn't print line numbers on mono/wasm either (in release/publish mode)
I just tested it.

Trying to understand whether we need extra work to get CoreCLR to parity with Mono Browser.

214KB is 4% of mono wasm hello world download size

StackTraceLineNumberSupport

Thanks!

[steveisok]

Mono doesn't use StackFrameHelper at all. It doesn't print line numbers on mono/wasm either (in release/publish mode) I just tested it.

I think from the BCL perspective it's still passing that it wants line numbers into an icall. I suspect we aren't getting them as a byproduct as opposed to doing something explicit for wasm.

[pavelsavara]

runtime/src/mono/mono/mini/mini-exceptions.c

Line 1456 in ebae784

mono_get_frame_info (gint32skip,

runtime/src/mono/mono/metadata/mono-debug.c

Lines 789 to 800 in ebae784

	/**
	* mono_debug_lookup_source_location:
	* \param address Native offset within the \p method's machine code.
	* Lookup the source code corresponding to the machine instruction located at
	* native offset \p address within \p method.
	* The returned \c MonoDebugSourceLocation contains both file / line number
	* information and the corresponding IL offset. It must be freed by
	* \c mono_debug_free_source_location.
	*/
	MonoDebugSourceLocation*
	mono_debug_lookup_source_location (MonoMethod*method, guint32address, MonoDomain*domain)
	{

[pavelsavara]

It seems to me that Mono functionality depends on debugger native module being linked in and also on PDB information being available.

[jkotas]

It doesn't print line numbers on mono/wasm either (in release/publish mode)

What does it do in debug builds?

[pavelsavara]

It doesn't print line numbers on mono/wasm either (in release/publish mode)

What does it do in debug builds?

Test exception for stack trace
at StopwatchSample.Baz() in D:\samples\debug-stack-trace\Program.cs:line 52
at StopwatchSample.Bar() in D:\samples\debug-stack-trace\Program.cs:line 48
at StopwatchSample.Foo() in D:\samples\debug-stack-trace\Program.cs:line 44
at StopwatchSample.Toggle() in D:\samples\debug-stack-trace\Program.cs:line 30
at StopwatchSample.<__Wrapper_Toggle_18729595>g____Stub|10_0(JSMarshalerArgument* ____arg_exception_native__param, JSMarshalerArgument* __invokeRetValUnmanaged__param) in D:\samples\debug-stack-trace\obj\Debug\net10.0\Microsoft.Interop.JavaScript.JSImportGenerator\Microsoft.Interop.JavaScript.JSExportGenerator\JSExports.g.cs:line 42
Error: Test exception for stack trace
at un (https://localhost:7005/_framework/dotnet.runtime.0j6ezsi0n0.js:3:27547)
at kn (https://localhost:7005/_framework/dotnet.runtime.0j6ezsi0n0.js:3:29564)
at Object.<anonymous> (https://localhost:7005/_framework/dotnet.runtime.0j6ezsi0n0.js:3:39269)
at HTMLButtonElement.<anonymous> (https://localhost:7005/main.ofkecrt505.js:26:47)

[jkotas]

So this PR will regress debug builds and improve size of release builds. I am not sure whether it is an improvement

[pavelsavara]

So this PR will regress debug builds and improve size of release builds. I am not sure whether it is an improvement

No this PR (in current shape) was conversation opener.

If we introduce that StackTraceLineNumberSupport as feature flag for that is false in browser release by default, we would be golden 🚀

[pavelsavara]

With [FeatureSwitchDefinition("System.Diagnostics.StackTrace.IsLineNumberSupported")] triggered by <StackTraceLineNumberSupport>false</StackTraceLineNumberSupport> by default in Release

Trimmed

Size is the same as above.

[pavelsavara]

[pavelsavara]

/ba-g CI timeouts