RuntimeHelpers.CreateSpan support is failing in some circumstances

[stephentoub]

dotnet/roslyn#61414 updated Roslyn with the ability to target RuntimeHelpers.CreateSpan. #79461 updates dotnet/runtime to pull in a newer version of Roslyn that contains the improvements and updates a bunch of code to take advantage of CreateSpan. But CI for that is failing due to ArgumentExceptions coming from CreateSpan due to what appears to be alignment issues. @davidwrighton is investigating, and I'm opening this to track, as we may need to back the changes out of Roslyn if it's an issue with the runtime or linker...

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[stephentoub]

There's at least one issue here in the Roslyn support. When the data is the 2/4/8 bytes in size, today it uses the built-in system types (short, int, long), but we shouldn't be doing so when the alignment is > 1, as those types have a .pack of 1, and thus a rewriter may not align the resulting data correctly. EDIT: These were fixed in dotnet/roslyn#65919.

It appears there may still be an additional issue beyond that, however, though I've only been able to repro the impact of the above locally.

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

Issue Details

---

dotnet/roslyn#61414 updated Roslyn with the ability to target RuntimeHelpers.CreateSpan. #79461 updates dotnet/runtime to pull in a newer version of Roslyn that contains the improvements and updates a bunch of code to take advantage of CreateSpan. But CI for that is failing due to ArgumentExceptions coming from CreateSpan due to what appears to be alignment issues. @davidwrighton is investigating, and I'm opening this to track, as we may need to back the changes out of Roslyn if it's an issue with the runtime or linker...

Author:	stephentoub
Assignees:	stephentoub
Labels:	area-System.Runtime.CompilerServices
Milestone:	-

[MichalStrehovsky]

There's at least one issue here in the Roslyn support. When the data is the 2/4/8 bytes in size, today it uses the built-in system types (short, int, long), but we shouldn't be doing so when the alignment is > 1, as those types have a .pack of 1, and thus a rewriter may not align the resulting data correctly.

We really should enforce this in the runtime and not wait for IL rewriters to break this - it was an unadressed piece of feedback when this was introduced: #63977 (comment). Roslyn using primitive types was specifically my example there :).

[stephentoub]

@sbomer, seems likely there's a linker bug here. Some of the legs in #79461 are failing catastrophically with errors like:

      System.ArgumentException : Value does not fall within the expected range.
      Stack Trace:
           at System.Runtime.CompilerServices.RuntimeHelpers.GetSpanDataFrom(RuntimeFieldHandle fldHandle, RuntimeTypeHandle targetTypeHandle, Int32& count)
        /_/src/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.cs(100,0): at System.Runtime.CompilerServices.RuntimeHelpers.CreateSpan[T](RuntimeFieldHandle fldHandle)
        /_/src/libraries/System.Private.CoreLib/src/System/Decimal.DecCalc.cs(140,0): at System.Decimal.DecCalc.get_DoublePowers10()
        /_/src/libraries/System.Private.CoreLib/src/System/Decimal.DecCalc.cs(1732,0): at System.Decimal.DecCalc.VarDecFromR8(Double input, DecCalc& result)
        /_/src/libraries/System.Private.CoreLib/src/System/Decimal.cs(195,0): at System.Decimal..ctor(Double value)
        /_/src/libraries/System.Private.CoreLib/src/System/Decimal.cs(935,0): at System.Decimal.op_Explicit(Double value)

I've attached the System.Private.CoreLib.zip binary from the failing Libraries Test Run checked coreclr windows x86 Debug leg (one of two checked legs hitting this widespread). The relevant field is:

.field /* 040021ED */ assembly static initonly valuetype '<PrivateImplementationDetails>'/'__StaticArrayInitTypeSize=648_Align=8' '67856A16DB0550FDAB4D1A9B208B0C155C4679CA116BF867B74ED2A0AA4D29558' at I_001B881C

Note the address 001B881C, which is not 8-byte aligned. But the associated type does have a .pack of 8:

.class /* 0200099D */ nested private explicit ansi sealed '__StaticArrayInitTypeSize=648_Align=8'
	extends System.ValueType
{
	.pack 8
	.size 648

} // end of class __StaticArrayInitTypeSize=648_Align=8

I can repro this locally. With the https://github.com/stephentoub/runtime/tree/usecreatespan branch, if I build with:

.\build.cmd clr.corelib -c checked -arch x86

I get the same erroneously-aligned address. But if I then edit the .\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj file to change the:

<ILLinkTrimAssembly>true</ILLinkTrimAssembly>

to:

<ILLinkTrimAssembly>false</ILLinkTrimAssembly>

I then get an 8-byte-aligned address of 004602C0, which makes sense given Roslyn 8-byte aligns every RVA field.

Can you take a look?

cc: @davidwrighton, @jcouv

Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

dotnet/roslyn#61414 updated Roslyn with the ability to target RuntimeHelpers.CreateSpan. #79461 updates dotnet/runtime to pull in a newer version of Roslyn that contains the improvements and updates a bunch of code to take advantage of CreateSpan. But CI for that is failing due to ArgumentExceptions coming from CreateSpan due to what appears to be alignment issues. @davidwrighton is investigating, and I'm opening this to track, as we may need to back the changes out of Roslyn if it's an issue with the runtime or linker...

Author:	stephentoub
Assignees:	stephentoub
Labels:	area-Tools-ILLink
Milestone:	8.0.0