Reply inline.
From: cfe-dev <cfe-dev-bounces@lists.llvm.org> On Behalf Of valerij zaporogeci
via cfe-dev
Sent: Thursday, July 1, 2021 3:54 PM
To: David Spickett <david.spickett@linaro.org>
Cc: cfe-dev@lists.llvm.org Developers <cfe-dev@lists.llvm.org>
Subject: [EXT] Re: [cfe-dev] Q: ARM, why -marm is ignored> > maybe there is another target, better suitable for a UEFI OSL
>
> Can you describe (or link to docs) what this means? What does a UEFI
> compatible executable involve, what format would it be, does it have
> to use Windows calling conventions, that sort of thing. (I'm not
> familiar with this area myself)The UEFI specification says (section 2.1.1 in 2.4.Errata_B, yes, it's
old, but I bet, it's the same in the newest one - compatibility), it
wants MachineType field for ARM32:
> #define EFI_IMAGE_MACHINE_ARMTHUMB_MIXED 0x01C2
As far as I can tell, outside of UEFI, this refers to Windows CE. LLVM doesn't support this at all; I think gcc called this target arm-wince-pe or something like that, before it was dropped. The Windows target supported by LLVM is the ABI for Windows on ARM (Windows 10).
So, the loader can be compiled to the Thumb instructions, but it has
to be "interworking" aware, and, as an indication of that, it should
use 1C2 machine type. And you know, what's funny, I just hexedited the
clang compiled image, changing MachineType from 1C4 to 1C2 and it
worked.without this, FW rejected to start it. So, if this is going
to be this optimistic, then this is the only change to be needed to
make it suitable for UEFI. Of course, pity, there is no way to tell
clang generate ARM only code.
You might be able to get away with this, I guess? Most of the relevant bits are pretty similar if you're targeting ARMv7, and don't need floating-point or unwinding.
The reason we ignore -marm is that Windows on ARM forbids switching to ARM mode. There isn't really any reason to switch, anyway, if you're targeting armv7.
>> as said in the title, gcc's -marm option (that is not reported as not recognized)
gets
>> absolutely ignored.
>
> The title I assume refers to clang. Do you mean gcc here, or clang?
> Would be good to compare the results if gcc is doing something
> different. (that doesn't make either correct just more data points)yes, clang, I just hoped, that passing to it this gcc option, would
make it generate ARM code fpr Windows targets. naivety.
probably does generate ARM code in this case, but gcc can't do PE, so
I didn't use it. I use MSVC, which generates Thumb, but when being
told about /subsystem:EFI_APPLICATION at least, sets 1C2 MachineType.
Teaching lld-link to fudge the MachineType is probably easy enough.
-Eli