MachOUtils.cs is not endian-independent.

[jkoritzinsky]

From #72394:

The problem seems to be that the new mono.tools subset now builds dotnet-pgo.csproj, which tries to create an osx-x64 shim apphost:

    <PackAsToolShimRuntimeIdentifiers>win-x64;win-x86;win-arm;osx-x64</PackAsToolShimRuntimeIdentifiers>

This in turn pulls in code in src/installer/managed/Microsoft.NET.HostModel/AppHost/MachOUtils.cs to manipulate MachO binaries, but that whole file unfortunately fundamentally seems to assume little-endian byte order, as it just mmaps the binary and then overlays structures over the mmap.

So the question is, what is the best way to fix this? Of course, we could try to rewrite MachOUtils.cs to be endian-independent. But I'm wondering if we even need to build this on s390x? Do you think it would make sense to skip building dotnet-pgo completely (or at least building the osx-x64 shim), either whenever PrimaryRuntimeFlavor is Mono or specificially just on s390x due to the endian issue?

Are the tools in dotnet-pgo even useful at all on a system where we're not supporting CoreCLR at all?

Originally posted by @uweigand in #72394 (comment)

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

From #72394:

The problem seems to be that the new mono.tools subset now builds dotnet-pgo.csproj, which tries to create an osx-x64 shim apphost:

    <PackAsToolShimRuntimeIdentifiers>win-x64;win-x86;win-arm;osx-x64</PackAsToolShimRuntimeIdentifiers>

This in turn pulls in code in src/installer/managed/Microsoft.NET.HostModel/AppHost/MachOUtils.cs to manipulate MachO binaries, but that whole file unfortunately fundamentally seems to assume little-endian byte order, as it just mmaps the binary and then overlays structures over the mmap.

So the question is, what is the best way to fix this? Of course, we could try to rewrite MachOUtils.cs to be endian-independent. But I'm wondering if we even need to build this on s390x? Do you think it would make sense to skip building dotnet-pgo completely (or at least building the osx-x64 shim), either whenever PrimaryRuntimeFlavor is Mono or specificially just on s390x due to the endian issue?

Are the tools in dotnet-pgo even useful at all on a system where we're not supporting CoreCLR at all?

Originally posted by @uweigand in #72394 (comment)

Author:	jkoritzinsky
Assignees:	-
Labels:	area-HostModel
Milestone:	-

[jkoritzinsky]

Extracting this comment out to a separate issue so if we hit it again, we can reference this (and consider fixing).

The existing case was mitigated by skipping building dotnet-pgo.csproj on S390X: #74147