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

[valerij zaporogeci via cfe-dev]

> > 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

and explains:

> This image type is chosen to enable UEFI images to contain Thumb and Thumb2
> instructions while defining the EFI interfaces themselves to be in ARM mode.

As of the calling convention, it's basically AAPCS:
> 2.3.5.3 Detailed Calling Convention
> The base calling convention for the ARM binding is defined here:
>   Procedure Call Standard for the ARM Architecture V2.06 (or later)
> http://infocenter.arm.com/
> This binding further constrains the calling convention in these ways:
> • Calls to UEFI defined interfaces must be done assuming that the target code requires
> the ARM instruction set state. Images are free to use other instruction set states except
> when invoking UEFI interfaces.
> • Floating point, SIMD, vector operations and other instruction set extensions must not
> be used.
> • Only little endian operation is supported.
> • The stack will maintain 8 byte alignment as described in the AAPCS for public
> interfaces.

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.

>> 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.

Thank you for your help.