Fix enumerating loaded process modules on Apple platforms

[davidwrighton]

• This logic always assumed that the lowest address of a mapped file was its "base address", but in the presence of Create a single copy of stub templates runtime#114462 that is no longer correct. We may map stubs at lower addresses.
• Fix by checking the start of the mapped region for the magic value for the start of a MachO binary

[hoyosjs]

Suggested change

	if (magic == 0xFEEDFACF)
	if (magic == 0xFEEDFACF || magic == 0xFEEDFACE)

[hoyosjs]

Looks like a few of the mappings have 0-offset entries:

/usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/System.Threading.dll
 address: 1091d0000 offset: 0
 protection: 1, max_protection: 7
 inheritance: 1
/usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/System.Threading.dll
 address: 10920c000 offset: 0
 protection: 3, max_protection: 7
 inheritance: 1
/usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/System.Threading.dll
 address: 109230000 offset: 10000
 protection: 1, max_protection: 7
 inheritance: 1
usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/libcoreclr.dylib
 address: 1054c4000 offset: 0
 protection: 5, max_protection: 7
 inheritance: 1
/usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/libcoreclr.dylib
 address: 10596c000 offset: 0
 protection: 1, max_protection: 7
 inheritance: 1
/usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/libcoreclr.dylib
 address: 10598c000 offset: 0
 protection: 3, max_protection: 7
 inheritance: 1
/usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.5/libcoreclr.dylib
 address: 1059b8000 offset: 4d0000
 protection: 1, max_protection: 7
 inheritance: 1

And attaching with a debugger - only the first one has the machO magic, despite all claiming offset 0.

[am11]

We can use this magic detection https://github.com/dotnet/runtime/blob/b6a87649d3538a49b1d406f782306c8c71896b59/src/installer/managed/Microsoft.NET.HostModel/MachO/MachObjectFile.cs#L139 enum at https://github.com/dotnet/runtime/blob/b6a87649d3538a49b1d406f782306c8c71896b59/src/installer/managed/Microsoft.NET.HostModel/MachO/Enums/MachMagic.cs#L9.

[hoyosjs]

yeah - we considered this as a "next possible thing". Remote reads just come with their own cost. We have similar logic in: https://github.com/dotnet/diagnostics/blob/main/src/Microsoft.FileFormats/MachO/MachOFatHeaderStructures.cs#L29

[hoyosjs]

Note in case this bites us in the future: flags isn't the most reliable here. There's the "cheaper" way of checking the remote bytes for the magic. The other option is using vm_* APIs to recognize the __TEXT section load.