[cfe-dev] Q: ARM, why -marm is ignored

[Eli Friedman via cfe-dev]

Reply inline.

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of valerij zaporogeci
> via cfe-dev
> Sent: Thursday, July 1, 2021 3:54 PM
> To: David Spickett <david.spickett at linaro.org>
> Cc: cfe-dev at lists.llvm.org Developers <cfe-dev at 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. :) gcc
> 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