[PATCH] D130239: [LoongArch] Encode LoongArch specific ELF e_flags to binary by LoongArchTargetStreamer

Lu Weining via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 27 19:23:00 PDT 2022


SixWeining added a comment.

In D130239#3683972 <https://reviews.llvm.org/D130239#3683972>, @xen0n wrote:

> In D130239#3683963 <https://reviews.llvm.org/D130239#3683963>, @SixWeining wrote:
>
>> In D130239#3678813 <https://reviews.llvm.org/D130239#3678813>, @xen0n wrote:
>>
>>> Do we have to wait before https://github.com/loongson/LoongArch-Documentation/pull/33 is merged (and perhaps the reference implementation in binutils) so we could mark LLVM-generated objects as such? The LLVM LoongArch port can never generate the old-style (stack-machine-style) relocs so I think this marker might be appropriate at all times.
>>
>> Yes, we do not plan to generate the old-style (stack-machine-style) relocs in LLVM that means we are targeting the socalled new-world. But that PR you mentioned has been open 8 months and I'm not sure when it would be merged, plus this one <https://github.com/loongson/LoongArch-Documentation/pull/47> . Maybe we can ignore them for now and leave a NOTE or TODO here so that we can move on to implement the other parts (relocs, ABI lowering in clang, inlineasm...)?
>
> I mentioned the PR because I saw activity from your team <https://github.com/loongson/LoongArch-Documentation/pull/33#issuecomment-1193465069>, leading to the conclusion that the PR would eventually get merged in a relatively short time. Meanwhile, for now there is no pressing reason to mark generated objects as such, because at present no tooling exists without the old-style relocs support; a NOTE or TODO works for me. Thanks.

Thanks. I just update the summary to reflect this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130239



More information about the llvm-commits mailing list