Remove support for non-indirect code headers

[davidwrighton]

• We use indirect code headers on all platforms (except for Windows X86, which has no particular reason to not use them)
  • Indirect code headers are required to support funclet style codegen, but work just fine in all cases.
• This removes one of the ways in which Windows X86 is different from all other platforms

[dotnet-policy-service]

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

[jkotas]

We use indirect code headers on all platforms (except for Linux X86

I do not think that this is correct.

https://github.com/dotnet/runtime/pull/100351/files#diff-acf2591196fce1cb929f939ad102f0859941d0b60b3070734d59f39af07920c7L54-L56 says that we do not use indirect code headers on Windows x86.

Having said this, I do not see a problem with switching Windows x86 to indirect headers if everything is green.

[AaronRobinsonMSFT]

Can someone give the "for Dummies" description for indirect and non-indirect code headers. What is the problem and how is it solved?

[jkotas]

Every JITed method has a code header that contains things like pointer to the method unwind/GC info, MethodDesc*, etc.

In indirect code header scheme, there is a pointer right before the start of the method code that points to the actual code header.

In "direct" code header scheme, the whole code header is right before the method code.

The indirect code header is better for code density and it allows the actual code header to be a variable sized struct that we take advantage of to store funclet bounds.

[davidwrighton]

@jkotas Thank you for correcting me on what platform didn't use these things. Having to have such arcane knowledge is why I want to get rid of this sort of weird variation that is OS/architecture specific. Also, allowed me to write a better PR comment :)

[jkotas]

Build breaks on Windows x86...

D:\a_work\1\s\src\coreclr\vm\codeman.cpp(2868): error C2039: 'unwindInfos': is not a member of '_hpRealCodeHdr'