Type manager indirection EEType vs. native layout signature
RalfKornmannEnvision opened this issue · comments
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.
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.
Fixed in #8271.