Type manager indirection EEType vs. native layout signature

[RalfKornmannEnvision]

Both the EEType node and the native layout signature node need to store a pointer to find the type manager at runtime.

For the EEType the compiler checks if the target support relative pointers and uses an absolute or relative symbol reloc:

           if (factory.Target.SupportsRelativePointers)
                objData.EmitReloc(factory.TypeManagerIndirection, RelocType.IMAGE_REL_BASED_RELPTR32);
            else
                objData.EmitPointerReloc(factory.TypeManagerIndirection);

But for the layout signature node it's always an absolute reloc

objData.EmitPointerReloc(factory.TypeManagerIndirection);

Beside of this the EEType node data is only placed on windows in the read only section while the native layout signature node does this always.

This results in a little bit of trouble for me on my ARM64/Switch combination. It might be a general ARM64 issue but I am not sure about this.

Anyway I end up with a static lib that contains absolute relocation's from the read-only section to the data section. When this lib is linked to the final executable the linker tells me that this relocation's can not be resolved without a dynamic relocation and that this is an error.

To get thinks running for now I am placing the native layout signature like the ee types just in the data section. I did a quick check with the linker by using a relative reloc for the native signature layouts. This works from a linker point of view but naturally fails at runtime.
As just changing the section is the easier fix for me I'd like to ask if there was a reason why the EE types do this (on non windows systems) but the native layout signatures not.

[MichalStrehovsky]

Changing the section should be a good fix. We've been fixing those as we were hitting issues with them (e.g. #5666). Most of this code originates in .NET Native that is Windows-only so there's still some places like this that we haven't fixed up to make ld happy.

Changing the pointer to be relative might potentially be a good space-saving optimization, but that can be looked at separately.

[MichalStrehovsky]

Fixed in #8271.