Building for target armv7a-win32-eabi not possible

Hello together,

I have a question regarding the the target triple armv7a-win32-eabi. I want to emit ARM code (not thumb code) for windows. The object file should be in COFF.
When calling clang++ with that target and the “–verbose” switch, I can see that the generated triple is “tumbv7–windows-eabi”. This is explicitly not what I specified as a target.
I then went ahead and changed the generated call to use “-triple armv7a–windows-eabi”. This resulted in the compiler error:

error: Function ‘func’ uses ARM instructions, but the target does not support ARM mode execution.
fatal error: error in backend: unsupported relocation type: fixup_arm_uncondbl

The question I have is, why is it prohibited to export ARM code for win32? When I replace “win32” with “none” I get no such error.

Best regards,
Jayvee

Hello Jayvee,

Hello together,

I have a question regarding the the target triple armv7a-win32-eabi. I want to emit ARM code (not thumb code) for windows. The object file should be in COFF.
When calling clang++ with that target and the "--verbose" switch, I can see that the generated triple is "tumbv7--windows-eabi". This is explicitly not what I specified as a target.
I then went ahead and changed the generated call to use "-triple armv7a--windows-eabi". This resulted in the compiler error:
> error: Function 'func' uses ARM instructions, but the target does not support ARM mode execution.
> fatal error: error in backend: unsupported relocation type: fixup_arm_uncondbl

The question I have is, why is it prohibited to export ARM code for win32? When I replace "win32" with "none" I get no such error.

My, somewhat limited, understanding is that Windows for Arm is
designed only for Thumb, for example there may be places in the tools
and the OS that don't handle interworking between Arm and Thumb
correctly. This prevents Arm instructions from being used safely on
the platform. When you remove the win32 with none you are removing
that platform specific restriction, however you are probably not
getting a Windows compatible COFF file out either.

I think you'll also not want EABI in your triple as that is the ELF
ABI and not the Windows compatible COFF ABI that you'll need on
Windows. You may want to try a target like thumbv7a-windows-msvc

Peter

Hello Peter,

thank you for the quick answer.

Actually I do want ARM code and not Thumb code. The dynamic library I try to build will be used from an environment that expects to call ARM code. I have no influence on the fact that I need ARM code. I am also supposed to link statically to a specialized prebuilt library providing runtime symbols such as “__rt_sdiv” (platform “none” will need symbols such as “__divsi3” for comparison). I have no influence on this circumstance, either.

This means the target armv7a-none-eabi is useless to me, as neither the object format nor the expected runtime functions match my requirements.

So the original problem remains.

Best regards,
Jayvee

Hello Peter,

thank you for the quick answer.
Actually I do want ARM code and not Thumb code. The dynamic library I try to build will be used from an environment that expects to call ARM code. I have no influence on the fact that I need ARM code. I am also supposed to link statically to a specialized prebuilt library providing runtime symbols such as "__rt_sdiv" (platform "none" will need symbols such as "__divsi3" for comparison). I have no influence on this circumstance, either.

This means the target armv7a-none-eabi is useless to me, as neither the object format nor the expected runtime functions match my requirements.

So the original problem remains.

I think that you may be out of luck using clang as the Windows on ARM
support is currently only Windows ARM NT which only supports Thumb,
hence the clang/llvm implementation only supports Thumb. My source is
https://reviews.llvm.org/D43005#1000822 . I'm guessing you are
targetting some kind of older Windows CE device that supported Arm
instructions?

Apologies I can't be of more help. Maybe some people in the US
timezone will know more.

Peter