[browser][coreCLR] Fix IP resolution for interpreted methods on WASM

[pavelsavara]

Motivation

The sampling profiler does not work on WASM because the EventPipe code paths that resolve instruction pointers (IPs) to method information assume the traditional InterpreterPrecode mechanism. On WASM, CoreCLR uses portable entrypoints (FEATURE_PORTABLE_ENTRYPOINTS) instead of interpreter precodes, so the existing code silently returns wrong or zero addresses, causing the profiler to fail to attribute samples to managed methods.

Split from #126324 for smaller reviews

Changes

src/coreclr/vm/prestub.cpp

When emitting the ETW MethodJitted event for interpreted methods, the code needs to extract the InterpByteCodeStart pointer to use as the native code start address. On non-WASM platforms this goes through InterpreterPrecode::FromEntryPoint → ByteCodeAddr. On WASM (FEATURE_PORTABLE_ENTRYPOINTS), this path doesn't exist — interpreter data is stored via PortableEntryPoint. The fix adds a conditional that uses PortableEntryPoint::GetInterpreterData(pCode) on WASM instead.

src/coreclr/vm/eventtrace.cpp

MethodAndStartAddressToEECodeInfoPointer resolves a MethodDesc + optional code address into a pointer suitable for ETW method events. The existing helper GetInterpreterCodeFromInterpreterPrecodeIfPresent is a no-op when FEATURE_PORTABLE_ENTRYPOINTS is defined (it just returns its input unchanged). The fix adds a fallback: when no explicit native code start address was provided, it queries MethodDesc::GetInterpreterCode() directly and returns the InterpByteCodeStart pointer. This allows the sampling profiler to correctly map sampled IPs back to interpreted methods on WASM.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR fixes EventPipe/ETW instruction-pointer (IP) to managed-method resolution for interpreted methods on WASM, where CoreCLR uses FEATURE_PORTABLE_ENTRYPOINTS instead of interpreter precodes. This enables the sampling profiler to correctly attribute samples to interpreted managed methods.

Changes:

• Update MethodDesc::JitCompileCodeLockedEventWrapper to derive the interpreted-method “native start address” from PortableEntryPoint interpreter data when FEATURE_PORTABLE_ENTRYPOINTS is enabled.
• Update MethodAndStartAddressToEECodeInfoPointer to fall back to MethodDesc::GetInterpreterCode() (returning the InterpByteCodeStart pointer) when no explicit start address is supplied on portable-entrypoint interpreter builds.

Reviewed changes

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

File	Description
src/coreclr/vm/prestub.cpp	Uses PortableEntryPoint::GetInterpreterData to compute the method start address for interpreted-method ETW events under portable entrypoints.
src/coreclr/vm/eventtrace.cpp	Adds a portable-entrypoints interpreter fallback so method events can resolve InterpByteCodeStart when no explicit start address is provided.

[Copilot]

The comment mentions getting the native start address from the interpreter Precode, but in the FEATURE_PORTABLE_ENTRYPOINTS branch the data comes from PortableEntryPoint interpreter data. Update the comment to reflect both cases; optionally, you could avoid duplicating the extraction logic by using MethodDesc::GetInterpreterCode() (which JitCompileCodeLocked already sets) when isInterpreterCode is true.

Suggested change

	// If this is interpreter code, we need to get the native code start address from the interpreter Precode
	// If this is interpreter code, get the native code start address from the
	// interpreter entrypoint data: PortableEntryPoint interpreter data when
	// FEATURE_PORTABLE_ENTRYPOINTS is enabled, otherwise the interpreter Precode.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

In the portable-entrypoints + interpreter fallback, the returned address should be encoded consistently with other interpreter code addresses (e.g., JitCompileCodeLockedEventWrapper passes PINSTRToPCODE(dac_cast<TADDR>(interpreterCode)) to ETW). Returning dac_cast<TADDR>(pInterpCode) bypasses PINSTRToPCODE, which can cause mismatches on architectures where PCODE carries tagging (e.g., ARM THUMB bit) and may break comparisons/method event correlation. Consider returning PINSTRToPCODE(dac_cast<TADDR>(pInterpCode)) (or equivalent) instead of the raw pointer value.

Suggested change

	return dac_cast<TADDR>(pInterpCode);
	return PINSTRToPCODE(dac_cast<TADDR>(pInterpCode));

[jkotas]

Should this be fixed in GetInterpreterCodeFromInterpreterPrecodeIfPresent instead?

Also, GetInterpreterCodeFromInterpreterPrecodeIfPresent may want to be renamed to GetInterpreterCodeFromEntryPointIfPresent to better represent what it does.