[PATCH] D145539: [llvm/Target] Add Windows COFF support for RISC-V

[Luo Jia via Phabricator via llvm-commits]

luojia marked an inline comment as done.
luojia added a comment.

In D145539#4176831 <https://reviews.llvm.org/D145539#4176831>, @jrtc27 wrote:

> In D145539#4176824 <https://reviews.llvm.org/D145539#4176824>, @luojia wrote:
>
>> In D145539#4176791 <https://reviews.llvm.org/D145539#4176791>, @jrtc27 wrote:
>>
>>> I'm guessing this is so you can llvm-objcopy an ELF into a PE/COFF?.. Because without relocations being defined you can't do much else of use...
>>
>> Yes llvm-objcopy can do this and this is the current approach on EDK2 RISC-V. But for languages like Rust it will be more convenient if the compiler backend writes it out directly from build target configuration
>
> And how are you going to do that without a full PE/COFF specification for RISC-V?

Thanks for mentioning! If I am correct, PE/COFF specification has definitions of machine architecture in headers. In this part PE/COFF included RISC-V architecture types. It does not provide relocation types on RISC-V, so for now PE/COFF specification allows us to emit RISC-V COFF binaries without any relocations. This could be a use case for RISC-V UEFI applications where it's mainly statically linked without any relocations. If there are more demands on RISC-V PE/COFF which need relocations, the current PE/COFF specification will not support them and LLVM (after this patch) would raise fatal error instead.

I have limited information about RISC-V PE/COFF support as well; I don't know if other reviewers have different opinion about this part.



================
Comment at: llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp:688
   const Triple &TT = STI.getTargetTriple();
   uint8_t OSABI = MCELFObjectTargetWriter::getOSABI(TT.getOS());
+
----------------
jrtc27 wrote:
> Can be after the if
Thanks! Modified.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145539/new/

https://reviews.llvm.org/D145539