Enable scripting of SuperPMI collection of crossgen2 compilations (#47513)
authorBruce Forstall <brucefo@microsoft.com>
Wed, 27 Jan 2021 19:37:31 +0000 (09:37 -1000)
committerGitHub <noreply@github.com>
Wed, 27 Jan 2021 19:37:31 +0000 (11:37 -0800)
commite8ffbad92fa20c8c2069373e8ce2b514fd509f85
tree35177a42619e010a332334582055396a972b80c2
parent0ff4f4ade4971e4f9e2db9fe393def70f40af64f
Enable scripting of SuperPMI collection of crossgen2 compilations (#47513)

`superpmi.py collect` has a new `--crossgen2` option that specifies
to run crossgen2 on all the assemblies specified with the
`-assemblies` option.

For example:
```
py c:\rt\src\coreclr\scripts\superpmi.py collect --crossgen2 -output_mch_path c:\win-x64-cg2.mch -assemblies c:\rt\artifacts\tests\coreclr\windows.x64.Checked\Tests\Core_Root\System.Private.CoreLib.dll
```

There are currently quite a few failures during the replay
"cleaning" phase with a System.Private.CoreLib collection:
5654 compilation failures out of 14705 functions, including 100
JIT asserts.

In contrast, the crossgen(1) collection has 3 failures out
of 20165 functions.

So, there is some work to be done to make SuperPMI collection
of crossgen2 compilations work well.

The change in spmirecordhelper.h is to work around what appears to
be a crossgen2 bug: when the JIT calls `getCallInfo`, sometimes crossgen2
sets sig.sigInst.methInstCount in the result CORINFO_CALL_INFO to non-zero,
but it sets sig.sigInst.methInst to `nullptr`, which should be illegal:
the count indicates how many elements are in the array, so you can?t have a
null array with a non-zero count. Maybe the JIT doesn?t look at these fields in this
scenario for some reason, but SPMI tries to serialize/de-serialize the array,
and was crashing.

Fixes #45909
src/coreclr/ToolBox/superpmi/superpmi-shared/spmirecordhelper.h
src/coreclr/scripts/superpmi.py