Allow building paltests without coreclr_misc

[uweigand]

Remove dependency on coreclr_misc for the paltests_install component.

@jkoritzinsky @jkotas With #49545 I added support for building clr.iltools and clr.paltests on a platform that doesn't support the coreclr JIT (s390x). However, after #49906 this stopped working again.

One of the problems in the new scheme is that the paltests now depend on coreclr_misc, which includes superpmi, which apparently depends on JIT internals and does not build on s390x. I don't really see why this dependency is necessary -- simply removing it fixes this problem for me again. (Separately, I'm wondering if superpmi shouldn't be part of the runtime component instead of coreclr_misc?)

Does this look reasonable to you or am I missing something here?

[ghost]

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

Issue Details

---

Remove dependency on coreclr_misc for the paltests_install component.

@jkoritzinsky @jkotas With #49545 I added support for building clr.iltools and clr.paltests on a platform that doesn't support the coreclr JIT (s390x). However, after #49906 this stopped working again.

One of the problems in the new scheme is that the paltests now depend on coreclr_misc, which includes superpmi, which apparently depends on JIT internals and does not build on s390x. I don't really see why this dependency is necessary -- simply removing it fixes this problem for me again. (Separately, I'm wondering if superpmi shouldn't be part of the runtime component instead of coreclr_misc?)

Does this look reasonable to you or am I missing something here?

Author:	uweigand
Assignees:	-
Labels:	area-Infrastructure-coreclr
Milestone:	-

[jkoritzinsky]

This looks reasonable to me.

[uweigand]

Thanks for the quick review! I still have more problems with getting back to building clr.iltools and clr.paltests on s390x, and I was wondering if you had some advice on the right direction to fix this here. On s390x we do not currently support the CLR JIT and runtime (only the Mono runtime), and therefore cannot build many of the subdirectories of coreclr, but we do need the iltools.

The main problem with the new model results from the fact that, when building e.g. just the iltools component, we still run cmake across all of coreclr. And this causes problems if there are subdirectories where even cmake cannot run successfully on unsupported architectures. This happens in particular in the jit and vm subdirectories (which abort with clr_unknown_arch), as well as in debug and unwind (which abort due accessing non-existing source files that are used unconditionally).

Now there seem to be two main options for how to fix this. One way would be to change the cmake files in those subdirectories so they can be processed on any architecture (e.g. by removing the clr_unknown_arch calls, and making sure any use of platform-specific files is guarded by an appropriate architecture check). Of course attempts to build would still fail - but the failure is moved from cmake time to compile time. (And that is fine, since we'd never be doing the compile step if we only build iltools.

The alternative would be to just go ahead and add support for our architecture (s390x) to those subdirectories, along the lines of the existing architectures. This would include adding the architecture-specific files that cmake expects (probably as stubs that error out at compile time).

If you have any suggestions on which way seems preferable (or anything else that I may be missing), this would be much appreciated!