Crossgen2 support for System.Private.CoreLib compilation in CoreCLR build

[trylek]

Fixes: #43810

[trylek]

/cc @dotnet/crossgen-contrib

Status update: the change kind of works to some extent with several caveats:

1. I still use Crossgen1 for emitting the PerfMap as this functionality is not yet implemeneted in CG2; I have created an issue to fix that and assigned to myself, Implement PerfMap generation in Crossgen2 #44123.

2. At this point I'm using R2RDump for emitting the PDB's. It may turn out to be easier to directly port the PdbWriter code to Crossgen2, I'm trying to figure that out.

3. Emitting PDB for Corelib Crossgen2-compiled with runtime release build on ARM crashes the R2RDump PDB emitter due to stream sync loss in GcInfo for the method System.Diagnostics.Tracing.ActivityTracker+ActivityInfo.AddIdToGuid(Guid *, int, uint, bool). This is super-weird as I'm always using the "-O" CG2 option, there's no apparent reason why debug / release CoreCLR build configuration should affect this.

4. The project file supports enforcing CG1 / CG2 mode via the "Crossgen1" / "Crossgen2" properties; when not set, it has a default of its own that is CG2 at the moment (to let me lab test the change). We need to decide if we want to continue lab testing CG1 and CG2 version in parallel, that would require wiring up the CG1 / CG2 selection logic through the YAML scripts.

5. I'm not sure if the cmd / sh scripts are worth keeping i.o.w. whether they're used for some special purpose as their parameters seem to suggest. We could make them thin wrappers calling msbuild on the project file with the appropriate properties set.

6. As part of the script logic there are bits of code for handling IBC / PGO instrumentation. @davidwrighton - is this still used somewhere? If it is, would there be a way for me to actually try that out so that I can test moving the option to the msbuild script?

Thanks

Tomas

[trylek]

/cc @dotnet/runtime-infrastructure as this has tendrils into the build system. Minor changes required to CoreCLR build order so that Crossgen2 is built before crossgenning Corelib. If we decide for temporary parallel lab testing of CG1 & CG2, one possible option is to model it as two clr build steps - something like "clr.crossgencorelib" vs. "clr.crossgen2corelib". That would be easy for access from the YAML scripts while somewhat more annoying to use locally - one option would be the default (the default clr build step set per eng/Subsets.props) and triggering "the other version" via explicit specification of the build substeps would be cumbersome. The other possibility is to just propagate it around the system as a global property ("use CG1 vs. CG2") akin to Configuration, for instance; it would probably need to be settable as an extra argument to the root build script or via some environment variables as I tried to outline in the current formulation of the change. I'll welcome any feedback as to what option you see as the cleanest and most reasonable.

[trylek]

Interestingly enough, out of the 11 failed legs in the build I claim my change only caused one, the CoreCLR release build on Windows ARM where R2RDump crashed on the GcInfo sync loss, the other ten leg failures are "someone else's problem" (which doesn't change the fact that my PR looks like it's crashing left and right in the lab).

[trylek]

The dotnet-runtime-perf failures are known and they are being currently investigated by @DrewScoggins. The last run ended up with a couple of failures in libraries / installer builds I believe to be unrelated to my change; I restarted them as I spotted some infrastructural hiccups in the failures. The failure in ARM Release build caused by R2RTest crash in GcInfo parsing is no longer happening after my latest change making GcInfo reading lazy. Overall I believe the change is ready to be reviewed and merged in. For now I haven't done anything about the crossgen_corelib.cmd / sh scripts.

[davidwrighton]

[mangod9]

Does this change require any communication to "repo committers" so they are aware in case they see any issues with crossgen-ing corelib?

[nattress]

LGTM!

[trylek]

@mangod9 - that is an interesting question. My expectation is that not much should actually change; and we've been covering the crossgenning of Corelib in multiple lab tests for quite a while. But in general some form of heads-up that we're starting the transition to Crossgen2 would be probably useful.

[sandreenko]

I suspect this change broke the native build on arm64 and arm because now when we try to run ./build.sh clr.nativecorelib -arch arm64 -c Debug -runtimeconfiguration Debug we get:

  Generating native image of System.Private.CoreLib for OSX.arm64.Debug. Logging to /Users/seandree/git/runtime/artifacts/log/CrossgenCoreLib_OSX__arm64__Debug.log
  /Users/seandree/git/runtime/artifacts/bin/coreclr/OSX.arm64.Debug/x64/crossgen /nologo  /Platform_Assemblies_Paths "/Users/seandree/git/runtime/artifacts/bin/coreclr/OSX.arm64.Debug/IL" /out "/Users/seandree/git/runtime/artifacts/bin/coreclr/OSX.arm64.Debug/System.Private.CoreLib.dll" "/Users/seandree/git/runtime/artifacts/bin/coreclr/OSX.arm64.Debug/IL/System.Private.CoreLib.dll"
  /var/folders/wq/w3ybc8px5xgb0r5k7g6tkkdm0000gp/T/tmp7fd421fa5bce4bacb6316a02f0b68db9.exec.cmd: line 2: /Users/seandree/git/runtime/artifacts/bin/coreclr/OSX.arm64.Debug/x64/crossgen: No such file or directory

we should not use CrossDir if HostArch is the same as the target.