Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RISC-V] Update TODOs for RiscV64 Machine and Architecture in Crossgen2 #97021

Merged
merged 1 commit into from
Feb 8, 2024

Conversation

ashaurtaev
Copy link
Contributor

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Jan 16, 2024
@clamp03 clamp03 added the arch-riscv Related to the RISC-V architecture label Jan 16, 2024
@clamp03
Copy link
Member

clamp03 commented Jan 16, 2024

If you don't mind, please set to draft before #95980 is merged.

@tomeksowi
Copy link
Contributor

#95980 is merged, I think you can rebase and re-open for review.

@ashaurtaev
Copy link
Contributor Author

@am11 After rebasing to the current main and installing the new dotnet-sdk-9.0.100-alpha.1.23615.4, I got the following errors:

/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/GCInfoTypes.cs(157,30): error CS0117: 'Machine' does not contain a definition for 'RiscV64' [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/GCInfoTypes.cs(173,30): error CS0117: 'Machine' does not contain a definition for 'RiscV64' [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/GCInfoTypes.cs(189,30): error CS0117: 'Machine' does not contain a definition for 'RiscV64' [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/GCInfoTypes.cs(207,30): error CS0117: 'Machine' does not contain a definition for 'RiscV64' [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/GCInfoTypes.cs(223,30): error CS0117: 'Machine' does not contain a definition for 'RiscV64' [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/TransitionBlock.cs(37,30): error CS0117: 'Machine' does not contain a definition for 'RiscV64' [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunReader.cs(636,30): error CS1061: 'Machine' does not contain a definition for 'RiscV64' and no accessible extension method 'RiscV64' accepting a first argument of type 'Machine' could be found (are you missing a using directive or an assembly reference?) [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunReader.cs(1420,38): error CS1061: 'Machine' does not contain a definition for 'RiscV64' and no accessible extension method 'RiscV64' accepting a first argument of type 'Machine' could be found (are you missing a using directive or an assembly reference?) [/home/runtime/src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ILCompiler.Reflection.ReadyToRun.csproj]
    0 Warning(s)
    8 Error(s)

What would cause it and what can be done to fix it?

@am11
Copy link
Member

am11 commented Jan 22, 2024

Normally it would mean to update System.Reflection.Metadata version here:

<SystemReflectionMetadataVersion>7.0.0</SystemReflectionMetadataVersion>

to something like: 9.0.0-alpha.1.24064.3 (which we are using in that file). However, this package, in particular, had required some coordination with other teams in the past: dotnet/arcade#10516. Not sure if that coordination is still needed, since sdk is using 8.0 while runtime is at 7.0, and code flow is working fine. @ViktorHofer, thoughts on updating S.R.M to latest alpha?

@ViktorHofer
Copy link
Member

Not sure if that coordination is still needed, since sdk is using 8.0 while runtime is at 7.0, and code flow is working fine. @ViktorHofer, thoughts on updating S.R.M to latest alpha?

cc @jaredpar @rainersigwald

@am11
Copy link
Member

am11 commented Jan 22, 2024

Ops sorry, the more relevant version is hardcoded to 6.0 here:

<!-- we need to keep the version of System.Reflection.Metadata in sync with dotnet/msbuild and dotnet/sdk -->
<PackageReference Include="System.Reflection.Metadata" Version="6.0.0" />
<PackageReference Include="System.Text.Json" Version="$(SystemTextJsonVersion)" />

@ashaurtaev, could you push the change with 9.0.0-alpha.1.24064.3 only in eng/Versions.props for SystemReflectionMetadataVersion (since that one is internal to runtime). Lets see how it well bodes with the CI. :)

@ViktorHofer
Copy link
Member

Which component needs a 9.0 version of SRM? If it's internal then that component might be better off using the live build of SRM.

Regardless, the HostModel version SRM version and others that are hardcoded should probably be updated to 8.0.0.

@ashaurtaev ashaurtaev force-pushed the update_riscv64_machine_in_crossgen2 branch from abfb512 to 1b0a3d5 Compare January 22, 2024 15:44
@ashaurtaev
Copy link
Contributor Author

@am11 I pushed the commit with an updated version of SystemReflectionMetadataVersion

@jaredpar
Copy link
Member

Not sure if that coordination is still needed, since sdk is using 8.0 while runtime is at 7.0, and code flow is working fine. @ViktorHofer, thoughts on updating S.R.M to latest alpha?

cc @jaredpar @rainersigwald

Not quite sure what you're looking for here from us.

@ViktorHofer
Copy link
Member

ViktorHofer commented Jan 22, 2024

Not quite sure what you're looking for here from us.

We noticed that some components like Microsoft.NET.HostModel are still on an older SRM:

<!-- we need to keep the version of System.Reflection.Metadata in sync with dotnet/msbuild and dotnet/sdk -->
<PackageReference Include="System.Reflection.Metadata" Version="6.0.0" />
<PackageReference Include="System.Text.Json" Version="$(SystemTextJsonVersion)" />

Is it important that we version consistently together? Based on HostModel which has been using 6.0.0 for two years now, I guess not. I assume we just can go higher but lower is fine?

@jaredpar
Copy link
Member

Hard for me to say cause I don't really know what that component is or what it does here.

@@ -128,7 +128,7 @@
<SystemDrawingCommonVersion>8.0.0</SystemDrawingCommonVersion>
<SystemIOFileSystemAccessControlVersion>5.0.0</SystemIOFileSystemAccessControlVersion>
<SystemMemoryVersion>4.5.5</SystemMemoryVersion>
<SystemReflectionMetadataVersion>7.0.0</SystemReflectionMetadataVersion>
<SystemReflectionMetadataVersion>9.0.0-alpha.1.24064.3</SystemReflectionMetadataVersion>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same version for SystemCollectionsImmutableVersion on line 125.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! I changed the version for SystemCollectionsImmutableVersion

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you apply this patch:

diff --git a/eng/Versions.props b/eng/Versions.props
index 9eafadc95df..5a46bfb7ad2 100644
--- a/eng/Versions.props
+++ b/eng/Versions.props
@@ -122,13 +122,14 @@
     <MicrosoftWin32RegistryVersion>5.0.0</MicrosoftWin32RegistryVersion>
     <StyleCopAnalyzersVersion>1.2.0-beta.507</StyleCopAnalyzersVersion>
     <SystemBuffersVersion>4.5.1</SystemBuffersVersion>
-    <SystemCollectionsImmutableVersion>9.0.0-alpha.1.24064.3</SystemCollectionsImmutableVersion>
+    <SystemCollectionsImmutableVersion>7.0.0</SystemCollectionsImmutableVersion>
     <SystemComponentModelAnnotationsVersion>5.0.0</SystemComponentModelAnnotationsVersion>
     <SystemDataSqlClientVersion>4.8.5</SystemDataSqlClientVersion>
     <SystemDrawingCommonVersion>8.0.0</SystemDrawingCommonVersion>
     <SystemIOFileSystemAccessControlVersion>5.0.0</SystemIOFileSystemAccessControlVersion>
     <SystemMemoryVersion>4.5.5</SystemMemoryVersion>
     <SystemReflectionMetadataVersion>9.0.0-alpha.1.24064.3</SystemReflectionMetadataVersion>
+    <SystemReflectionMetadata_CrossRepoSync_Version>7.0.0</SystemReflectionMetadata_CrossRepoSync_Version>
     <SystemSecurityAccessControlVersion>6.0.0</SystemSecurityAccessControlVersion>
     <SystemSecurityCryptographyCngVersion>5.0.0</SystemSecurityCryptographyCngVersion>
     <SystemSecurityCryptographyOpenSslVersion>5.0.0</SystemSecurityCryptographyOpenSslVersion>
diff --git a/src/installer/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj b/src/installer/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj
index cdd3751e3c2..89f6f938536 100644
--- a/src/installer/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj
+++ b/src/installer/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj
@@ -20,7 +20,7 @@
 
   <ItemGroup>
     <!-- we need to keep the version of System.Reflection.Metadata in sync with dotnet/msbuild and dotnet/sdk -->
-    <PackageReference Include="System.Reflection.Metadata" Version="6.0.0" />
+    <PackageReference Include="System.Reflection.Metadata" Version="$(SystemReflectionMetadata_CrossRepoSync_Version)" />
     <PackageReference Include="System.Text.Json" Version="$(SystemTextJsonVersion)" />
   </ItemGroup>
 
diff --git a/src/tasks/Microsoft.NET.WebAssembly.Webcil/Microsoft.NET.WebAssembly.Webcil.csproj b/src/tasks/Microsoft.NET.WebAssembly.Webcil/Microsoft.NET.WebAssembly.Webcil.csproj
index d09ae4a569a..677f9dc6150 100644
--- a/src/tasks/Microsoft.NET.WebAssembly.Webcil/Microsoft.NET.WebAssembly.Webcil.csproj
+++ b/src/tasks/Microsoft.NET.WebAssembly.Webcil/Microsoft.NET.WebAssembly.Webcil.csproj
@@ -17,7 +17,7 @@
   <ItemGroup>
     <!-- we need to keep the version of System.Reflection.Metadata in sync with dotnet/msbuild and dotnet/sdk -->
     <PackageReference Include="System.Memory" Version="$(SystemMemoryVersion)" /> 
-    <PackageReference Include="System.Reflection.Metadata" Version="$(SystemReflectionMetadataVersion)" />
+    <PackageReference Include="System.Reflection.Metadata" Version="$(SystemReflectionMetadata_CrossRepoSync_Version)" />
     <PackageReference Include="System.Collections.Immutable" Version="$(SystemCollectionsImmutableVersion)" />
   </ItemGroup>

I think this will resolve @ViktorHofer's concern.

Copy link
Member

@ViktorHofer ViktorHofer Jan 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you need the latest SCI anymore? nit consider SystemReflectionMetadataToolsetVersion over SystemReflectionMetadata_CrossRepoSync_Version as the property name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you need the latest SCI anymore?

it is only needed by wasm project. Perhaps other consumers of the package would benefit if it’s decoupled as well? (can be done in a separate PR)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extracted these changes in a separate PR: #97643. @ashaurtaev if that one gets merged first, you can undo the changes here:
git checkout HEAD~3 -- ':/eng'
and merge upstream main.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! I'll wait for your PR to be merged and then rebase my PR

@ViktorHofer
Copy link
Member

ViktorHofer commented Jan 22, 2024

@am11 there might be dragons, i.e.

<!-- we need to keep the version of System.Reflection.Metadata in sync with dotnet/msbuild and dotnet/sdk -->
<PackageReference Include="System.Memory" Version="$(SystemMemoryVersion)" />
<PackageReference Include="System.Reflection.Metadata" Version="$(SystemReflectionMetadataVersion)" />
<PackageReference Include="System.Collections.Immutable" Version="$(SystemCollectionsImmutableVersion)" />

I'm not sure if bumping the centrally defined version is the right thing to do.

@am11
Copy link
Member

am11 commented Jan 22, 2024

I'm not sure if bumping the centrally defined version is the right thing to do.

Yes, we can pin it the other way around (for now ™️); use 9.0-alpha in ILCompiler.Reflection.ReadyToRun.csproj instead.

Maybe we should add something like SystemReflectionMetadata_CrossRepoSync_Version for Microsoft.NET.HostModel.csproj and Microsoft.NET.WebAssembly.Webcil.csproj? Currently the former has hardcoded version and latter is using central.

@ViktorHofer
Copy link
Member

Maybe we should add something like SystemReflectionMetadata_CrossRepoSync_Version for Microsoft.NET.HostModel.csproj and Microsoft.NET.WebAssembly.Webcil.csproj? Currently the former has hardcoded version and latter is using central.

Yes I think that would be good. Would you mind opening an issue to track that?

@rainersigwald
Copy link
Member

The relevant build scenario is:

  1. In .NET Framework MSBuild (or VS):
  2. Some .NET SDK build tasks use HostModel.
  3. HostModel uses core libraries like System.Collections.Immutable and System.Reflection.Metadata.
  4. MSBuild also uses those, and provides binding redirects to the VS version.
  5. This can cause runtime mismatches when the version resolved in the HostModel context (and bumped through MSBuild binding redirects to generally the last released version) doesn't match the version directly referenced by SDK build tasks (generally that's the current version--9.0.0.0 now).

I think if everything in the SDK references a 9.0 version it'll be fine, the problems come up when, for example, HostModel is old or has a stale reference.

@ashaurtaev
Copy link
Contributor Author

@am11, how to proceed? Do I need to wait for #96809 to complete?

@am11
Copy link
Member

am11 commented Jan 29, 2024

#97021 (comment) I think this will address @ViktorHofer's concern, and unblock this PR.

@ashaurtaev ashaurtaev force-pushed the update_riscv64_machine_in_crossgen2 branch from 30c1618 to 73800e9 Compare February 6, 2024 13:35
@ashaurtaev
Copy link
Contributor Author

Runtime build for riscv64 completed successfully

@ashaurtaev
Copy link
Contributor Author

@am11 @ViktorHofer Please take a look at this pr since #97643 has been merged

@am11 am11 requested a review from jkotas February 8, 2024 11:35
Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the right person to review this change since it touches runtime and the ILCompiler. cc @jkotas @MichalStrehovsky

@am11
Copy link
Member

am11 commented Feb 8, 2024

Part of #96438

Should it be Fixes #96438 or is there something still missing?

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@jkotas jkotas merged commit 5a9e1e7 into dotnet:main Feb 8, 2024
145 of 152 checks passed
@ashaurtaev ashaurtaev deleted the update_riscv64_machine_in_crossgen2 branch February 8, 2024 14:05
@github-actions github-actions bot locked and limited conversation to collaborators Mar 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-riscv Related to the RISC-V architecture area-crossgen2-coreclr community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.