UnsafeAccessorAttribute fails to access volatile field

[filipnavara]

Description

When trying to access volatile string private field through UnsafeAccessorAttribute, MissingFieldException is thrown.

Reproduction Steps

using System;
using System.Runtime.CompilerServices;

var a = new A();
Console.WriteLine(GetSetFoo(a));

[UnsafeAccessor(UnsafeAccessorKind.Field, Name = "foo")]
extern static ref string GetSetFoo(A args);

class A { private volatile string? foo = "Bar"; }

Expected behavior

The program output is Bar.

Actual behavior

Unhandled exception. System.MissingFieldException: Field not found: 'A.foo'.
   at Program.<<Main>$>g__GetSetFoo|0_0(A args)
   at Program.<Main>$(String[] args) in D:\unsafeaccessor\Program.cs:line 5

Regression?

No response

Known Workarounds

No response

Configuration

This seems to be broken both in .NET 8 and .NET 9 with CoreCLR runtime. Tested on Windows and macOS.

Other information

The question of modreqs/modopts came up in the original feature proposal and this was the answer (#81741 (comment)):

And how would this interact with modreqs and modopts that can't be specified in C# (e.g. the IsExternalInit modifier on init property setters / volatile fields etc)?

Yeah, modreqs and modopts would be complicated. I think we will skip modreqs and modopts for the signature match.

This originally came up in KirillOsenkov/MSBuildStructuredLog#834.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

[filipnavara]

Additionally, this does work in both .NET 8 and .NET 9 with NativeAOT publishing.

[am11]

This seems to be broken both in .NET 8 and .NET 9 with CoreCLR runtime.

I can repro it on osx-arm64 with .NET 9.0.0 and .NET 10.0.0-alpha.1.24553.1 (dotnet run) but not with .NET 8.0.10. Also, it doesn't repro on sharplab net8.0.

[jkotas]

cc @AaronRobinsonMSFT

[AaronRobinsonMSFT]

This is likely because of

runtime/src/coreclr/vm/prestub.cpp

Line 1501 in 35d2780

state.IgnoreCustomModifiers = false;

It might be the case we should always ignore custom modifiers for fields.

[AaronRobinsonMSFT]

Yep, setting IgnoreCustomModifiers to true makes this work, but the generated accessor isn't going to be correct since we don't currently emit the .volatile prefix for the ldsfld/ldfld instructions. I can see an argument that this is "unsafe" but skipping the .volatile really seems wrong. Let me try and special case volatile.

[AaronRobinsonMSFT]

Looks like there isn't any need to update the generated getters. See #109694.