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

David Spickett via cfe-dev cfe-dev at lists.llvm.org
Thu Jul 1 02:06:41 PDT 2021


Clang changes the triple in arm::setArchNameInTriple before passing it
to llvm. Arm (32 bit) Windows is always set to thumb.

$ ./bin/clang --target=armv7a-unknown-windows-eabihf -c /tmp/test.c -o
/tmp/test.o -###
<...> "/home/david.spickett/build-llvm-aarch64/bin/clang-13" "-cc1"
"-triple" "thumbv7-unknown-windows-eabihf" <...>

Then in the backend we also do the same thing. So passing individual
features to llvm is probably not going to work, it'll just get
overridden.

llvm/lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.cpp:172
if (TT.isOSWindows()) {
  if (!ARMArchFeature.empty())
    ARMArchFeature += ",";
  ARMArchFeature += "+noarm";
}

llvm/lib/Target/ARM/ARMSubtarget.cpp:206
// FIXME: this is invalid for WindowsCE
if (isTargetWindows())
  NoARM = true;

So I can't think of a way around it, without using a non Windows target name.

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

> (I wish I could find info about all of them)? for example, as a wild guess, I gave it "efi" instead of "windows" and it accepted it

I suspect it didn't know what "efi" was and defaulted to elf. Triples
are not parsed in a very strict way, I agree it would be nice to have
"valid triples are ...".

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

On Thu, 1 Jul 2021 at 02:03, valerij zaporogeci via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> Hi, I wanted to compile a UEFI OS loader with clang (as well) for 32
> bit ARM, but, it turned out, that clang always generates Thumb only
> code and sets MachineType to 1c4 (ARMv7 (or higher) Thumb mode only),
> which is not what UEFI wants, it wants 1c2 (ARM or Thumb). I am
> compiling, setting the target to "armv7a-unknown-windows-eabihf".
> maybe there is another target, better suitable for a UEFI OSL (I wish
> I could find info about all of them)? for example, as a wild guess, I
> gave it "efi" instead of "windows" and it accepted it, however
> generated an ELF object file. as said in the title, gcc's -marm option
> (that is not reported as not recognized) gets absolutely ignored. tell
> me please:
> 1) what target should I use to generate a UEFI compatible executable
> (MachineType 1c2)?
> 2) is there a way to force clang generate ARM mode only code for
> windows (PE) targets?
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


More information about the cfe-dev mailing list