EFI images have wrong machine type for 32-bit ARM

[maharmstone]

Using the triplet thumbv7-w64-mingw32 and (e.g.) -Wl,--subsystem,efi_boot_service_driver you can create EFI images for 32-bit ARM, but these don't load without a bit of tweaking. EFI is expecting an image type of IMAGE_FILE_MACHINE_ARMTHUMB_MIXED (0x1c2), but lld is outputting IMAGE_FILE_MACHINE_ARMNT, 0x1c4, which I believe is what 32-bit ARM Windows uses. See also the gnu-efi linker script for this: https://github.com/rhboot/gnu-efi/blob/master/gnuefi/crt0-efi-arm.S

If lld gets passed a subsystem which begins with "efi_", it should be outputting a machine type of 0x1c2 rather than 0x1c4.

[maharmstone]

Ping @mstorsjo. I swear I've seen some code somewhere that does precisely this (binutils?) but I can't find it now.
Please also let me know if I'm doing something stupid and there's a way to do this already

[mstorsjo]

Ping @mstorsjo. I swear I've seen some code somewhere that does precisely this (binutils?) but I can't find it now. Please also let me know if I'm doing something stupid and there's a way to do this already

I'm not aware of a way of doing this right now.

If it is just a case of setting a different machine ID, I guess this could work, but I would think that there can be a few more issues involved:

• I'm not sure the dynamic base relocations that are relevant for IMAGE_FILE_MACHINE_ARMNT are relevant for IMAGE_FILE_MACHINE_ARMTHUMB_MIXED (I see 0x1c2 named IMAGE_FILE_MACHINE_THUMB in WinSDK headers, and within binutils). The one specific for ARMNT is IMAGE_REL_BASED_ARM_MOV32T. Then again, I'm not sure how this works in the context of EFI - do dynamic relocations (i.e. if the image is loaded at a different address than the fixed one) even come into play there?
• I'm not sure if the older ARM PE/COFF variants (IMAGE_FILE_MACHINE_ARM, 0x1c0 or IMAGE_FILE_MACHINE_THUMB, 0x1c2) use different object file relocations. Then again, those only matter for the relocatable objects; it doesn't matter for the end resulting image what actual relocations were used for producing it...
• Does that kind of image need some sort of proper interworking between ARM and Thumb modes? The LLD COFF linker for the ARMNT target assumes everything is Thumb2 everywhere, so it doesn't do any interworking but just forcibly sets the thumb bit on every address where it is relevant.

I.e. in short - feel free to experiment and see if this change is the only thing you need to change, or if more things are needed. If it's just about switching the final machine ID based on subsystem name, I guess that can be acceptable, but there's a risk that this endeavour does require a bunch more changes in various places as well.