NativeAOT SuperPMI collections

[TIHan]

This adds NativeAOT SuperPMI collections runs for the SmokeTests. Will work on windows+linux x64+arm64.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	TIHan
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[TIHan]

@dotnet/jit-contrib @BruceForstall this is ready.

[BruceForstall]

Generally LGTM

[jakobbotsch]

@TIHan Can you please check the superpmi-collect runs you have been triggering for errors? E.g. I see all the "libraries pmi" runs failing with

Console log: '0' from job c74f489f-b165-4186-a8d9-e8f2f0f058df workitem 43264b0b-93c7-4f6b-b133-873825bb3b3b (ubuntu.2204.amd64.rt) executed on machine a0001QC running Linux-5.15.0-1041-azure-x86_64-with-glibc2.35
chmod: cannot access '/datadisks/disk1/work/AC490993/w/A220090C/e/*.sh': No such file or directory
+ /usr/bin/python3 /datadisks/disk1/work/AC490993/p/superpmi/superpmi.py collect --clean -log_level DEBUG --pmi -pmi_location /datadisks/disk1/work/AC490993/p/superpmi/pmi.dll -pmi_path /datadisks/disk1/work/AC490993/p/superpmi/R2RDump /datadisks/disk1/work/AC490993/p/superpmi/R2RTest /datadisks/disk1/work/AC490993/p/superpmi/crossgen2 /datadisks/disk1/work/AC490993/p/superpmi/xunit -assemblies /datadisks/disk1/work/AC490993/w/A220090C/u/binaries -arch x64 -build_type checked -core_root /datadisks/disk1/work/AC490993/p/superpmi -output_mch_path /datadisks/disk1/work/AC490993/w/A220090C/uploads/libraries.pmi.0.linux.x64.checked.mch -log_file /datadisks/disk1/work/AC490993/w/A220090C/uploads/libraries.pmi.0.linux.x64.checked.log
[00:29:45] ================ Logging to /datadisks/disk1/work/AC490993/w/A220090C/uploads/libraries.pmi.0.linux.x64.checked.log
Specify `-ilc_rsps` if `--nativeaot` is given
+ export _commandExitCode=1
+ exit 1
['0' END OF WORK ITEM LOG: Command exited with 1]

(link)

[BruceForstall]

I looked at a recent collection run and see a few concerning things:

2023-09-07T00:19:46.5692728Z cp: cannot create regular file '/mnt/vss/_work/1/s/artifacts/obj/': Not a directory
2023-09-07T00:19:46.5692958Z cp: cannot create regular file '/mnt/vss/_work/1/s/artifacts/obj/': Not a directory
2023-09-07T00:19:46.5693150Z /mnt/vss/_work/1/s/eng/native/version/copy_version_files.sh: line 29: /mnt/vss/_work/1/s/artifacts/obj/_version.c: No such file or directory

Why are these failing? What script/process is the invoker?

2. Failures during collection

Unhandled exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/mnt/vss/_work/1/s/artifacts/tests/coreclr/obj/linux.x64.Checked/Managed/nativeaot/SmokeTests/SharedLibrary/SharedLibrary/native/SharedLibrary.exports'.
...
Unhandled exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/mnt/vss/_work/1/s/src/tests/nativeaot/SmokeTests/DynamicGenerics/rd.xml'.
...
Unhandled exception: System.CommandLine.CommandLineException: '/mnt/vss/_work/1/s/src/tests/nativeaot/SmokeTests/TrimmingBehaviors/NonEmbedded.ILLink.Descriptor.xml' doesn't exist

Are these files built when the smoke tests are built? Are they just not getting copied to Helix?

[TIHan]

Why are these failing? What script/process is the invoker?

This one I am not sure.

Are these files built when the smoke tests are built?

Except for the .exports file, the .xml files are located where the source of the tests are. Which means we would have to do more work to get these files copied over.

Are they just not getting copied to Helix?

I updated it to at least copy over the .exports file, but I can't copy the .xml ones because they are not part of the output of the tests.

Seeing how there are multiple tests, when built, that will not include the non-DLL files they depend on in the output, it may make sense to do something similar to what @MichalStrehovsky suggested. I was hoping that it would be just the assemblies and the pinvokelist.

@BruceForstall What do you recommend we do? We get tens of thousands of method contexts so it still works well enough - we can iterate on it over time.

[BruceForstall]

LGTM