Fix DacTableGen build on Windows ARM64

[AntonLapounov]

Building Runtime on a Windows ARM64 machine would produce the ARM64 version of DacTableGen.exe with the x64 version of msdia140.dll, which would result in a BadImageFormatException. The fix is to copy the correct version of msdia140.dll. Below is the tree structure of the %VSINSTALLDIR%DIA SDK\BIN directory:

DIA SDK\BIN
│   msdia140.dll
├───amd64
│       msdia140.dll
├───arm
│       msdia140.dll
└───arm64
        msdia140.dll

[ghost]

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

Issue Details

---

Building Runtime on a Windows ARM64 machine would produce the ARM64 version of DacTableGen.exe with the x64 version of msdia140.dll, which would result in a BadImageFormatException. The fix is to copy the correct version of msdia140.dll.

Author:	AntonLapounov
Assignees:	-
Labels:	area-Diagnostics-coreclr
Milestone:	-

[AntonLapounov]

The failure in the test is # 45326.

[hoyosjs]

With this change, an x86 build ends up with this if it uses the global dotnet (x64). We always tend to use amd64. I aggree with the ARM64 part though, as long as you're not doing x86 emulation (are you using the native SDK)?

    BUILDMSG: System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (0x8007000B)
       at Dia.Util.DiaFile.DllGetClassObject(Guid rclsid, Guid riid)
       at Dia.Util.DiaFile.GetDiaSourceClass()
       at Dia.Util.DiaFile..ctor(String pdbFile, String dllFile)
       at PdbSymbolProvider..ctor(String symbolFilename, String dllFilename)
       at Shell.DoMain(String[] args)
       at Shell.Main(String[] args)

[AntonLapounov]

@hoyosjs Could you please provide more details on your scenario? build -arch x86 succeeds for me and it uses .dotnet\dotnet.exe, which is an x64 binary. The x86 build in this PR succeeded as well.

[hoyosjs]

.\build.cmd Clr.DacTools+Clr.Runtime -rc release -arch x86 when BuildArchitecture is x86. However, I realized to get there users most likely need to go out of their way. There's also enough testing in place anyway such that if this regresses the official build, we would notice it (not in PR), so this feels OK. All the caveats for this are by setting BuildArchitecture (say x86 to try and force the use of a particular architecture under ARM64 emulation). On second thought this is already problematic in several places.

[hoyosjs]

With this, are you able to drive the full build on ARM64 with an ARM64 SDK?

[hoyosjs]

Thanks!

[AntonLapounov]

With this, are you able to drive the full build on ARM64 with an ARM64 SDK?

To build ARM64 on an ARM64 machine, we also need to resolve a couple of issues with crossgen2 and build-runtime.cmd, which forces building and using x64 binaries even when running on ARM64:

runtime/src/coreclr/build-runtime.cmd

Lines 230 to 233 in add68df

	if %__BuildArchArm64%==1 (
	set __BuildArch=arm64
	set __CrossArch=x64
	)

We need to check the true machine architecture, and if it is ARM64, we should not set cross-building variables for the tools we build ourselves.