Fix incorrect codemanager implementation on x86

[tommcdon]

This addresses windows x86 debugger setip issues introduced by #114170

[dotnet-policy-service]

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

[Copilot]

Pull Request Overview

This PR fixes debugger setup issues on Windows x86 by addressing the incorrect implementation of the code manager.

• Introduces a new DecodeGCHdrInfo method in jitinterface.cpp that uses a relative offset to compute the correct GC header info pointer.
• Updates all affected call sites in eetwain.cpp to pass the proper structure (using a value instance and its address) and a dwRelOffset parameter.
• Updates the codeman.h header with the new function prototype to support x86 changes.

Reviewed Changes

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

File	Description
src/coreclr/vm/jitinterface.cpp	Added the new DecodeGCHdrInfo method for proper GC header info decoding
src/coreclr/vm/eetwain.cpp	Modified calls to DecodeGCHdrInfo and adjusted usage of the hdrInfo structure
src/coreclr/vm/codeman.h	Added the function prototype for DecodeGCHdrInfo

Comments suppressed due to low confidence (1)

src/coreclr/vm/eetwain.cpp:90

• Verify that the updated API for GetHandlerFrameInfo (which now accepts a pointer to hdrInfo) is consistently implemented across all call sites.

GetHandlerFrameInfo(&hdrInfoBody, ctx->Ebp,

[filipnavara]

Thanks! There's one code path that could possibly benefit from the cache optimization (GetAmbientSPFromCrawlFrame -> GetAmbientSP seems to use the same relOffset as the cache in EECodeInfo) but it's not worth the extra trouble, it is only used by debugger.

I'm sorry for breaking this but I assume there're no public tests that would alert me about this, right?

[tommcdon]

Thanks! There's one code path that could possibly benefit from the cache optimization (GetAmbientSPFromCrawlFrame -> GetAmbientSP seems to use the same relOffset as the cache in EECodeInfo) but it's not worth the extra trouble, it is only used by debugger.

I've pushed a commit to take advantage of the perf improvement when the relative offset matches the code manager's built-in offset.

I'm sorry for breaking this but I assume there're no public tests that would alert me about this, right?

No worries. You are correct - we have some internal Visual Studio testing that caught the issue.