GCCoverageInfo support 32-bit Tiered compilation

[AaronRobinsonMSFT]

Update the GC coverage info code path to respect Tiered compilation on a 32-bit platform.

Fixes #36366

/cc @AndyAyersMS @kouvel

[kouvel]

LGTM, thanks!

[AndyAyersMS]

Seems a little odd to me that native code versions aren't tied in more closely to the jit manager and so can be obtained from a code address with less ceremony.

@AaronRobinsonMSFT have you checked that this fixes the test case?

[AaronRobinsonMSFT]

@AndyAyersMS Yep. I locally validated this fixes the issue reported in #36366. I also ran through several other GC stress scenarios in other tests.

[AaronRobinsonMSFT]

Seems a little odd to me that native code versions aren't tied in more closely to the jit manager and so can be obtained from a code address with less ceremony.

@AndyAyersMS I agree. I wish I knew the history behind this design. It makes bugs like this feel even more like the tip of the iceberg rather than one offs.

Does my change here align with your approach?

[AndyAyersMS]

Yes, it's the same approach that I started working up. I hit the lock level assert and didn't go further.

[kouvel]

Seems a little odd to me that native code versions aren't tied in more closely to the jit manager and so can be obtained from a code address with less ceremony.

Yea maybe the native code version could be stored instead of the method desc or something like that. Not sure about fragile ngen images and its jit manager, maybe it had something to do with that, or the size since it's a bit larger. Would be nice to be able to get the code version without a lock.