A plain empty entry point function that returns 0 seems to produce a binary that loads and runs fine in wine.
Details
Diff Detail
Event Timeline
Can you add a testcase?
This patch seems too simple to submit. Do you think you can improve it so that you can create an executable that does nothing but just exit with 0?
Added a testcase, sorted the ARM64 declaration alphabetically.
The test case checks the pe32+ magic value, which llvm-readobj doesn't output (yet), but I'll send a separate patch for that.
Yes; the executable built by the test does that - tested in wine (which is the only arm64 windows environment I've got; prior to this patch it didn't work).
test/COFF/arm64-magic.test | ||
---|---|---|
2 | Rename this file arm64-magic.yaml and merge with Inputs/arm64-executable.obj.yaml. |
Does this patch emits other headers correctly? See lld/test/COFF/hello32.test as an example for i386.
I think it's mostly right enough so far, although I haven't checked everything in detail yet - at least it seemed right enough for wine to run, and after fixing the is64 function, most of the critical flags seem to match the upstream microsoft arm64 exes I've got to compare to.
But at least you want to make sure that these bits are updated for ARM64, right?
HEADER: Format: COFF-i386 HEADER-NEXT: Arch: i386 HEADER-NEXT: AddressSize: 32bit HEADER-NEXT: ImageFileHeader { HEADER-NEXT: Machine: IMAGE_FILE_MACHINE_I386 (0x14C)
Added a few more trivial cases where the arm64 machine type is mapped, extended the test to check more flags. I've doublechecked the flags that the test checks with binaries from microsoft.
Rename this file arm64-magic.yaml and merge with Inputs/arm64-executable.obj.yaml.