Fix Armel crossgen failing during pack

[ThadHouse]

Armel was not treated like arm or arm64, causing the wrong folders to be used during crossgen.

Closes #45056

[trylek]

LGTM, thank you!

[jmorrill]

Thank you for this PR. It helped me eventually get an armel build. There are a few issues, but not sure if its related to this or not.

1.) The dotnet-runtime-6.0.0-dev-linux-armel.tar.gz contains the x64 libclrjit.so. The nupkg contain the correct armel binaries.
The build output (-v verbose) shows it does the right thing at first, then overwrites libclrjit.so with the wrong version.

6:3>Done building target "GetFilesToPublish" in project "Microsoft.NETCore.App.Runtime.sfxproj".
6:3>Target "PublishToDisk" in file "/home/jmorrill/.nuget/packages/microsoft.dotnet.sharedframework.sdk/6.0.0-beta.20609.9/targets/sharedfx.targets" from project "/home/jmorrill/core/runtime/src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Runtime.sfxproj" (entry point):
Task "Error" skipped, due to false condition; ('$(OutputPath)' == '') was evaluated as ('/home/jmorrill/core/runtime/artifacts/obj/Microsoft.NETCore.App.Runtime/Release/net6.0/linux-armel/output/' == '').
Task "Copy"
..
Copying file from "/home/jmorrill/core/runtime/artifacts/bin/coreclr/Linux.armel.Release/sharedFramework/libclrjit.so" to "/home/jmorrill/core/runtime/artifacts/obj/Microsoft.NETCore.App.Runtime/Release/net6.0/linux-armel/output/shared/Microsoft.NETCore.App/6.0.0-dev/libclrjit.so".
...
Copying file from "/home/jmorrill/core/runtime/artifacts/bin/coreclr/Linux.armel.Release/x64/sharedFramework/libclrjit.so" to "/home/jmorrill/core/runtime/artifacts/obj/Microsoft.NETCore.App.Runtime/Release/net6.0/linux-armel/output/shared/Microsoft.NETCore.App/6.0.0-dev/libclrjit.so".".

2.) The crossgen'd libraries seem to create incorrect code in the build process. When I execute a simple console application there are odd floating point issues. For example: Console.WriteLine(1f / 3f) would output "0". A new Timespan would hold seemingly random values.
Rerunning crossgen (w/ readytorun flag) on the armel device fixed this. There are similar issues with AspnetCore. I had to put the libraries though crossgen on an armel device to make them work w/o odd managed exceptions. Makes sense with Aspnet as armel doesnt seem to be a supported arch in the build process. I'm out of my depth on this, but I suspect crossgen might be generating armhf readytorun.

[ThadHouse]

Hmm. I had tested that the build had ran, but I wonder if something else broke. I'll look at my build to see which libclrjit was used.

For the crossgen issue, I wonder if it generated armhf code. On most armv7 systems, that will compile and run, other then the fact interop code will receive parameters in the wrong spot. Console.WriteLine likely ends up being a native call, so this wouldn't shock me.

[jmorrill]

Hmm. I had tested that the build had ran, but I wonder if something else broke. I'll look at my build to see which libclrjit was used.

For the crossgen issue, I wonder if it generated armhf code. On most armv7 systems, that will compile and run, other then the fact interop code will receive parameters in the wrong spot. Console.WriteLine likely ends up being a native call, so this wouldn't shock me.

Thank you for looking into this! Not sure if it helps, but my build env and config is:
WSL2 Ubuntu
sudo ROOTFS_DIR=/home/jmorrill/armel ./eng/common/cross/build-rootfs.sh armel
ROOTFS_DIR=/home/jmorrill/armel ./build.sh -c release -arch armel -cross -subset clr+libs+host+packs -clang9

I've tried with this PR:
git fetch origin pull/45058/head && git checkout FETCH_HEAD

And tried with this PR cherry picked on a later commit from Dec 12th (60b6af1)

[trylek]

@ThadHouse - sorry about the delayed response, this change has somehow fallen through the cracks. I have resolved your branch against the latest runtime bits. If you could double-check that it works fine for you, that would be awesome; otherwise I'll probably just check this in tomorrow once the runtime PR tests finish and I'll let you follow up separately.

[trylek]

The x86 failure is known, #45326.