[llvm-dev] fixup_aarch64_movw support for COFF AArch64

[Martin Storsjö via llvm-dev]

On Wed, 2 Oct 2019, Adam Kallai wrote:

> I'm working Chromium targeting Windows on ARM64 platform. As a part of this 
> work I ran into an issue related to llvm in Swiftshader.
>
> Currently fixup_aarch64_movw relocation type is not supported for COFF ARM64 
> (AArch64WinCOFFObjectWriter). As far as I see, Microsoft hasn't defined 
> indicator for this relocation type. I haven't seen documented anywhere.
>
> For AArch32 mova/movt indicators were implemented, I'm not sure but maybe we 
> need to have something similar for AArch64?

The AArch32 movw/movt relocation was for a true relocation, where the 
target of the relocation is a symbol that is unknown at the assembly 
stage. But for AArch64 there is no such relocation defined for COFF.

> Could someone give me some pointers how I could handle/fix this?

I'm not entirely sure, but it seems like this fixup type is only used for 
absolute values that are resolved before the object file is written - from 
AArch64AsmBackend.cpp, adjustFixupValue:

   case AArch64::fixup_aarch64_movw:
     [...]
     if (!IsResolved) {
       // FIXME: Figure out when this can actually happen, and verify our
       // behavior.
       Ctx.reportError(Fixup.getLoc(), "unresolved movw fixup not yet "
                                       "implemented");
       return Value;
     }

Despite this, it seems like AArch64ELFObjectWriter::getRelocType does 
return some ELF/AArch64 specific relocation types for this (but which 
never end up emitted to object files).

I tried adding an error in AArch64AsmBackend.cpp for this fixup type and 
running the tests in llvm/test/MC (I didn't check other parts of the 
testsuite), and it broke two tests, MC/AArch64/fixup-absolute.s and 
MC/AArch64/fixup-absolute-signed.s. And these two produce ELF object files 
without relocations.

So I would aim at making these two testcases work for COFF files, which 
shouldn't require making up any new COFF relocation types, at least not 
ones that would end up visible outside of the lib/Target/AArch64 
internals.

// Martin