[Mono] Implement support for UnsafeAccessorAttribute

[lambdageek]

Implement support for "zero overhead member access with suppressed visibility checks" #81741 for the mono JIT/AOT and interp

• Add UnsafeAccessorAttribute as a well-known attribute to the runtime
  We will need to extract a named string-value property from the custom attribute ([Mono] UnsafeAccessorAttribute non-generic support for field #88626)
• Add code to JIT/AOT and the interp transform to detect static extern methods with the attribute and trigger emitting the method wrapper for UnsafeAccessor ([Mono] UnsafeAccessorAttribute non-generic support for field #88626)
• Implement some ilgen code to generate the method bodies for these methods for the non-generic case
  • Field ([Mono] UnsafeAccessorAttribute non-generic support for field #88626)
  • StaticField ([Mono] UnsafeAccessorAttribute non-generic support for field #88626)
  • Constructor, Method, StaticMethod ([mono] Some UnsafeAccessorAttribute support for methods and constructors #88925)
  • [mono] Support UnsafeAccessorAttribute method calls with custom modifiers #89098
    (test cases: Verify_IgnoreCustomModifier, Verify_UnmanagedCallConvBitAreTreatedAsCustomModifiersAndIgnored, Verify_ManagedUnmanagedFunctionPointersDontMatch and Verify_InvalidTargetUnsafeAccessorAmbiguousMatch)

There might be some mild complication here for working with generics (the static extern method will be generic in that case) - our ilgen method builder might not support generics (in which case it will have to be extended)

[lambdageek]

/cc @SamMonoRT

[lambdageek]

It doesn't look like we will need anything special to skip accessibility checks for fields

For something like

class MyClass {
  private MyFieldType MyField;
  ...
}

[UnasafeAccessor(UnsafeAccessorKind.Field, Name="MyField")]
static extern ref MyFieldType GetMyField(MyClass c);

the ilgen could use mono_mb_emit_ldarg and mono_mb_emit_ldflda which would emit

  ldarg.0
  mono_custom_prefix . mono_objaddr
  add <field_offset>

---

for method calls, mono_mb_emit_managed_call just uses a normal IL call instruction (nit: we actually want callvirt) so we might need some prefix opcode to skip accessibility checks. (or we understand that this ilgen'd method should skip accessibility checks entirely - I think we already have that for wrappers)

[lambdageek]

For generic field access we can't use mono_objaddr + add <constant>, so we'll have to use a real ldflda instruction. Which probably means we should just have a tag on the method to bypass access checks and then do things with normal IL opcodes.

[AaronRobinsonMSFT]

@lambdageek I've added #86161 for CoreCLR.

[lambdageek]

There's also a question of when do we create the IL for this "extern" method which is sort of interesting. I think for JIT/AOT we can actually do it during the call to mono_compile_method_checked. Not sure when to do it in the interpreter.

I guess the question is whether the same logic that we use for dllimports and icalls will work for plain "extern" methods. (I'm pretty sure that's not the case - we look for the internalcall or pinvokeimpl flags, not just methods with no code)

[lambdageek]

I guess the thing to pattern this on is where we call mono_marshal_get_delegate_begin_invoke: in mono_interp_transform_method and compile_special

and in general we probably should treat these as special kind of wrappers, kind of like MONO_WRAPPER_DELEGATE_BEGIN_INVOKE.

So we should add new subtypes of MONO_WRAPPER_OTHER for unsafe accessors and use the wrapper emit logic (incl caching) to generate the bodies. it just happens that the wrapper does all the real work and the underlying method has no code.

[lambdageek]

From #81741 (comment):

The plan has been to avoid special casing these extern methods with this attribute in Roslyn in any way. It means that these extern methods would be MethodImplAttributes.IL just like any other extern method.

In CoreCLR, we plan to check for zero RVA first, and then for the attribute if the method has zero RVA. If a method with non-zero RVA is marked with this attribute, it is going to be no-op. We do not plan to do sanity checks for invalid use of this attribute on methods with non-zero RVA.